5 ms·

Getting to zero exceptions is not a sensible goal (in languages where error handling is done through exceptions). Not all exceptions are bugs. What's supposed t

Getting to zero exceptions is not a sensible goal (in languages where error handling is done through exceptions). Not all exceptions are bugs. What's supposed to happen when a network connection goes down?

Roboprog 11y ago
While that is a good counter example, it would be nice to have 0 exceptions (ERROR and the like) logged on most days. I have seen too many apps/modules that throw up and log just because of bad user input. This noise gets tedious to wade through to find the real problems.
- fauigerzigerk 11y ago
  Isn't this simply a question of choosing the right logging levels?
vietor 11y ago
As per the article: -Expected exceptions get turned into metrics If it's not a bug, mute it in your exception tracker and measure it.
- fauigerzigerk 11y ago
  To turn something into useful metrics there needs to be more than zero of it the first place. So maybe the right way of putting it would be to say "Don't just log bugs. Fix them!". Calling that "zero exceptions" is misleading.
  - vietor 11y ago
    That's why the article is "Getting to Zero" not "Starting at Zero"; the target audience is teams where the opening quotes sound like something you'd overhear. Not understanding the negativity. It was a reasonably well done little blog post, and if you're on, or responsible for, a team where that situation and attitude is occurring it provides some good concise guidelines on how to make life better.
grhmc 11y ago
I'd write an error handler which may issue retries, or roll back transactions, and then log that it did timeout (instead of letting it bubble up to the top.)
mmanfrin 11y ago
I think it is a wholly sensible goal for a web app. If a network connection goes down, it is helpful to the user to inform them of what is going on rather than 500ing; or, if it's an async job, retries are appropriate. An exception is the end of a flow and is generally unhelpful for customer-facing tools. An exception should mean 'hey, a user did some edge case that illuminated an issue we should fix'.
- mikegioia 11y ago
  Why is an Exception only something final? Exceptions can be caught, even by type. I regularly use exceptions to break and resume long-running daemons. These exceptions have nothing to do with the user nor the end to the program. I don't think Exception == Fatal Error.
rikkus 11y ago
The terminology is important here. If by error handling you mean usual flow control when something off the happy path occurs, that is subtly but crucially different from a condition or event that could not have been foreseen. On all the platforms I have developed on that have exceptions, exceptions are for situations that I don't know how to recover from with logic that is really part of my app anyway... This includes network connections dropping as that's not something I couldn't foresee. Sometimes if you work with this approach you find that the designers of the libraries upon which you build have, frustratingly, decided to force you to catch exceptions to deal with business as usual, but generally I find that treating exceptions as 'cannot continue' has worked well for most code I've written in the last 12 years.

Roboprog 11y ago

While that is a good counter example, it would be nice to have 0 exceptions (ERROR and the like) logged on most days. I have seen too many apps/modules that throw up and log just because of bad user input. This noise gets tedious to wade through to find the real problems.

fauigerzigerk 11y ago
Isn't this simply a question of choosing the right logging levels?

vietor 11y ago

As per the article: -Expected exceptions get turned into metrics If it's not a bug, mute it in your exception tracker and measure it.

fauigerzigerk 11y ago
To turn something into useful metrics there needs to be more than zero of it the first place. So maybe the right way of putting it would be to say "Don't just log bugs. Fix them!". Calling that "zero exceptions" is misleading.
- vietor 11y ago
  That's why the article is "Getting to Zero" not "Starting at Zero"; the target audience is teams where the opening quotes sound like something you'd overhear. Not understanding the negativity. It was a reasonably well done little blog post, and if you're on, or responsible for, a team where that situation and attitude is occurring it provides some good concise guidelines on how to make life better.

grhmc 11y ago

I'd write an error handler which may issue retries, or roll back transactions, and then log that it did timeout (instead of letting it bubble up to the top.)

mmanfrin 11y ago

I think it is a wholly sensible goal for a web app. If a network connection goes down, it is helpful to the user to inform them of what is going on rather than 500ing; or, if it's an async job, retries are appropriate. An exception is the end of a flow and is generally unhelpful for customer-facing tools. An exception should mean 'hey, a user did some edge case that illuminated an issue we should fix'.

mikegioia 11y ago
Why is an Exception only something final? Exceptions can be caught, even by type. I regularly use exceptions to break and resume long-running daemons. These exceptions have nothing to do with the user nor the end to the program. I don't think Exception == Fatal Error.

rikkus 11y ago

The terminology is important here. If by error handling you mean usual flow control when something off the happy path occurs, that is subtly but crucially different from a condition or event that could not have been foreseen. On all the platforms I have developed on that have exceptions, exceptions are for situations that I don't know how to recover from with logic that is really part of my app anyway... This includes network connections dropping as that's not something I couldn't foresee. Sometimes if you work with this approach you find that the designers of the libraries upon which you build have, frustratingly, decided to force you to catch exceptions to deal with business as usual, but generally I find that treating exceptions as 'cannot continue' has worked well for most code I've written in the last 12 years.