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.
_______________________________________________
mobile-firefox-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/mobile-firefox-dev
