There's a relationship here but I wouldn't say it's entirely an `Error` vs. `Exception` issue.

With the changes to Trapperkeeper in PE-3657, if any form of `Throwable` were bubbled up to the framework from a service within its `init` function, Trapperkeeper would subsequently call stops on each of the services which had been bootstrapped.  If the Jetty service's `init` hadn't been called or bubbled up a `Throwable`, the Jetty server instance would not have been attached to the context.  When the Jetty service's `stop` function were subsequently called, a pre-condition check for `started?` here would fail -- because no Jetty server instance would be on the context.  The code in PE-3659 essentially made the presence of a Jetty server instance on the context optional.  If it is present during shutdown, stop is called on it.  Otherwise, nothing happens -- no `Throwable` thrown back up to the Trapperkeeper framework.

Trapperkeeper does a try/catch block around stop calls -- catching for type `Exception`.  If an `AssertionError` were thrown, the JVM process would die from the `AssertionError` with some potential cleanup not being done.  Even if Trapperkeeper were catching `Throwable` more generically here instead, though, it seemed best to avoid cascading up the `Throwable` from the Jetty service since logging the problem during the `stop` phase didn't seem to make sense.