Yeah, we wanted to have all of the non-JVM hook *shutdown* stuff be initiated from a single point in the code -- code already in `run-app` -- rather than create new locations -- e.g., within the TrapperkeeperApp instance or `boot-services*` -- in which shutdowns could be initiated.

Yep, after the first error which occurs in either an `init` or `start` function, no additional `init` or `start` functions would be called.  Just the `stop` functions would be called so that the services have a chance to cleanup resources they had previously created before the app would shut down.

The only reason I included the try/catches here rather than just using the wrapper try/catch in `boot-services*` is that I noticed that when using the "reloaded" repl example that a stack trace wasn't being listed for any `Throwable` being thrown in an `init` or `start` method.  The try/catch in `init` and `start` here is just for logging the `Throwable` so it can be seen across the different methods in which services can be inited or started.