3 ms·
> You don't know which exceptions will be raised in advance. > Most of exceptions are unrecoverable (that's why they are called exceptions), the best course of
by BrandoElFollito 4y ago
> You don't know which exceptions will be raised in advance.
> Most of exceptions are unrecoverable (that's why they are called exceptions), the best course of action is to crash, which happens by default.
I prefer to propagate such unknown exceptions to a top-level catch to clanly log that something happened.
I usually have two types of exceptions: the ones I expect at some point (a HTTP call failing for some reason) that I may ("when I have time") group in "known exceptions we should not worry about" and log them as "informational", and exceptions I did not anticipate that I want to log as well, but with a critical level because they were, well, unexpected.
So crashing right when they happen may not be the best strategy.
- sandinmyjoints 4y agoI really wish English had different individual words for the concepts "known [problem] we should not worry about" and "[problems] I did not anticipate".
- cduzz 4y agowarning (a not fatal thing happened; took too long) error (a fatal thing I was expecting happened; I couldn't reach the API) exception (a fatal thing I wasn't expecting happened; the runtime fault handler did a thing named XYZ)
- hbrn 4y agoERROR and WARNING log levels. Everything goes to ERROR by default, some errors get downgraded to WARNING when you confirm they are not important. Send ERRORs to Sentry (or whatever you use) and deal with them immediately. Send WARNINGs to your favorite centralized logging solution and deal with them when there's too many.