>  core/start-webserver is going to start the jetty server on a background thread, right? And that background thread is where the exception will get thrown? 

No, that's not true.  Jetty actually opens the socket and attempts to bind the listener on the same thread on which the .start() call to the Jetty Server object is made.  So the `BindException` which is thrown when the bind fails is caught by the catch in the `shutdown-on-error*` function.

Without the `shutdown-on-error` wrapper, the `BindException` would be cascaded back up to `build-app*` and the app would be shutdown.  The Jetty Server object, however, doesn't get written onto the context.  When the Jetty service's `stop` is called, there's no Jetty `Server` object available to call stop on.  The process would then hang indefinitely because the Server listener thread would never be shut down.

With the `shutdown-on-error` wrapper, the shutdown promise is set and so Trapperkeeper will know it needs to shut down once it gets to the point of waiting on the promise.  The Jetty Server object, which was created but just never *completely* started, will be available on the context and, therefore, available for stop to be called on it.

Another way I could have done this, probably, would be to just have a try/catch around the `core/start-webserver` call and in the catch block call `.stop()` on the Jetty Server, and re-throw the exception up the stack.  One benefit to doing it the latter way, I suppose, is that you'd get faster-fail behavior -- Trapperkeeper wouldn't bother making further `start` calls on any services before shutting everything down.  The primary reasons I didn't go with that were that I was looking to have the shutdown logic process in only one place -- the service `stop` function -- and the amount of code to write was less.

I could be talked into doing the faster-fail behavior, though, if you think it is preferrable.  WDYT?