It's rather the opposite, it helps avoid bugs when something is terminated, e.g. by ensuring that if an exception is thrown it rolls back a database transaction

It's rather the opposite, it helps avoid bugs when something is terminated, e.g. by ensuring that if an exception is thrown it rolls back a database transaction. Generally you want to do several classes of things with exceptions in web apps: 1. Return a 500, possibly rendering a nice error page. 2. Log why it occurred. 3. Roll back changes you were making at the time in the database. And you might also want to do other things, like propagate the error via tracing, increment monitored metrics and many other things. All these are easily done with exceptions, and will often be done by frameworks for you. In desktop apps you may also want to trigger a crash reporter, display a sorry message to the user, and if the exception was inside something like a button click handler you may even be able to proceed safely too. Given the level of bugginess in untested error handling codepaths that crop up in languages without them, exceptions are definitely the way to go.