I would like to get another opinion on this one before going with `check-for-errors!` over `shutdown-requested?` / `get-shutdown-reason` given the additional utility for more granular troubleshooting and a little cleaner looking (in my opinion, anyway) API the latter could provide.  

I think it's worth noting that the current implementation of `check-for-errors!` wouldn't give any visibility to a `request-shutdown` requested by the app.  I don't currently have it in the classification of an *error* that would translate up into an exception.  This is mostly due to semantics.  Not sure `request-shutdown` calls automatically indicate an *error*.  The `shutdown-requested?` / `get-shutdown-reason` implementation didn't classify shutdown reasons as *errors* per se, so shutdown requests through `request-shutdown` would be made visible through the `shutdown-requested?` / `get-shutdown-reason` approach.

Assuming we would go with `check-for-errors!`, would it make sense to have the implementation throw an exception for any kind of shutdown requested -- even ones triggered from `request-shutdown`?  For example, the implementation could just throw a generic Exception with the shutdown `:cause` in the text.  If none of this seems like that big of a deal, I could just leave the implementation as is.