To clarify ...

Within my “persistent programs” of any sort, the outer level request handler contains an all-encompassing “exception handler of last resort,” and it carefully examines just what sort of exception has been thrown.

That is the reason why I use exception classes, which are objects.   (Yes, you can die with an object, as well as with a string.)   Code that cannot succeed throws an exception of a particular class.   (If it invokes code that might not use these classes, it “wraps” that code in an inner exception-handler which throws an exception-class containing among other things the text.)   Some exceptions are used as a way to gracefully bail-out from anywhere.   Others truly represent detected program flaws.   The outer-level handler will catch that fly-ball if nobody else does, and will do something appropriate.

It is true that any exception can leave various kinds of “smoking remains” which can accumulate; especially memory.   It happens often enough that Plack, for instance, has a so-called “hara kiri” facility which causes the workers to periodically die-off.   Sometimes the appropriate response to a certain exception is to die-off immediately.   But the outer level handler still has to capture the error traceback (another feature of these exception classes) and to sound the alarm somewhere.

Absolutely the worst thing that can happen is an exception that causes incomplete output and that is not correctly trapped or logged as an exception.   We have all seen web sites and so-forth that have done this.   Usually the output just stops in m

;-)