2 ms·
The vast majority of my error handling is for failures you really can't do anything about locally (e.g. network connection died, couldn't connect to database, c
by seanwilson 6y ago
The vast majority of my error handling is for failures you really can't do anything about locally (e.g. network connection died, couldn't connect to database, couldn't write to file system) so a few try/catches close to the top-level of the program (instead of strewed across all your files) are pretty ideal for me when working on e.g. frontend, games, simple backend APIs.
For cases like "user not found" and "incorrect password", ideally I'm going to have proper option types that statically check I'm handling the success/failure flows. Which "errors" go into option types and which errors go into exceptions is a design choice that's dependent on the domain.
I'm guessing people that don't like exceptions are working in domains that need lots of careful local error handling?
I'm not seeing where the problem is to be honest. Every approach can be abused somehow if a programmer wants to excessively suppress errors.