Not sure if I can do that exactly how you were thinking.

If the "(tka/check-for-errors! app)" call were inside of the let block like the "tka/init" call is and would throw an exception, the new value of app would not end up being bound to "system".  I don't think we'd want that because then you wouldn't be able to call reset/stop and have resources be cleaned up.  Maybe I could have app be let bound before the alter-var-root call is made so that app is still in scope and can be used to check for an error after the alter-var-root call has completed.  Not sure if that's a significant improvement?

On the original PR, we talked about whether we needed to plumb anything up to the TrapperkeeperApp instance or could just reuse the internal function -- `get-app-shutdown-reason` -- instead.  I agree that plumbing it through the App instance makes it friendlier to use but had been thinking about deferring that to a later ticket just to keep the scope of this PR down a bit, with the thinking that we'd just have the reloaded example use the internal function for now.  Sounds like maybe I should revisit that and go ahead and plumb the shutdown reason up through the TrapperkeeperApp interface?