Catching generic Exceptions

[Ben Bucksch]

JR Conlin wrote on 01.09.2015 01:04:
> At my last employer, catching all exceptions was considered a bad 
> thing. Granted, that was providing a service, so failing out meant, at 
> worst, the remote connection had to be re-established. I'll agree that 
> eating exceptions here is probably not a bad thing since killing the 
> browser would not be a good user experience. 

Agreed. That's the big difference. Thanks for explaining the *reason* 
for the 2 different schools of thoughts.

In UIs, I always catch all exceptions at the level where the action was 
originally initiated - that's usually the event handler attached to the 
UI element.
If I can recover from an error at a lower level, I do.
If I cannot, I construct a user-friendly error message on the low level, 
then bubble up the exception to the event handler, and there I catch all 
exceptions and show an error message to the user. The error message can 
then show in the UI context where it was initiated, which sometimes is 
in a popup dialog, and sometimes a red inline text in a window, e.g. in 
a login window that stays open until the login is complete, with 
progress indicator and inline error display.

> The reasonable exception I make is when we don't control the code that 
> could be throwing

Agreed.

> In general, we will never spot an error if we log or catch. Only 
> developers will see those, and if you're muffling to avoid 
> user-visible behavior, succeeding means nobody will notice!

Yes, agreed. Never eat errors. The user needs to know what exactly (!) 
went wrong.