5 ms·

I think what the post is trying to say is that you should let your exception bubble up. And then catch it at the highest level, including all the stack trace.

I think what the post is trying to say is that you should let your exception bubble up. And then catch it at the highest level, including all the stack trace. And then maybe send it to sentry, or log it, put it on data dog. But don't catch exceptions all over your application code. I have a related mental model for this: When you crash, crash loudly.

masklinn 5y ago
That, however, does not at all work when exceptions are part of the "normal" process and should be ignored or cleanly retried (having spent a while interacting with github, if you take the entire thing down every time github replies with an error and log that to sentry, your sentry instance will last all of 5mn before you have to declare bankruptcy or just plonk the alters and ignore everything). But in that case you probably still want to know about these failures, so you can review them from time to time, or see if there are upticks in failure frequency.
- Veuxdo 5y ago
  Exceptions should not be normal by definition.
  - deleted 5y ago
    [deleted]
  - contravariant 5y ago
    With some systems I have indeed been tempted a few times to only throw an exception if everything went right in one try, but my suggestions have been rejected so far.
  - mkohlmyr 5y ago
    That's a wonderful theory. I have a third party which returns errors ~20% of the time outside of working hours (yes, really). 1. Exceptions should be sent to sentry. 2. Exceptions should not be normal. 3. Do not log. Solve for ability to review & debug after the fact.
    - Veuxdo 5y ago
      If it doesn't work that often, then it isn't an expectation. That's just how it works.
    - frenchyatwork 5y ago
      > I have a third party which returns errors ~20% of the time outside of working hours Then presumably those errors shouldn't be exceptions. Of course, there's a lot of a lot of assumptions behind this: 1. You have control over the code that interfaces with the third party. Otherwise presumably you'd have to write a shim that catches the exception and turns it into an error value, and that's probably not worth the effort. 2. You're work in a language that doesn't type check exceptions (i.e. not Java with checked exceptions) and your language also doesn't have a nicer way of handling errors as a (discriminated) union. 3. Your co-workers will go complete bananas if you start using some sort of result type or [success, value|error] tuple instead of an exception because that's how they've done it for 20 years. The reason for this is that exceptions in most languages escape the type system and are in general more awkward to catch. Of course, I'd also disagree with "do not log" in this context, though I might prefer a logging mechanism that allowed me to write queries on it (like recording values in a database).
      - marcosdumay 5y ago
        Well, unless it's reasonable for your own software to fail the same 20% of the time (well, more, but knowing how much more requires more information) when outside of working hours, you will always need a shim anyway.
  - chousuke 5y ago
    In some languages, the standard way to signal failure is to throw an exception. You can't really define exceptions as abnormal in those cases, because failures are part of normal operation; you can't expect them not to happen if you want robust software.
    - Veuxdo 5y ago
      Why not return an error in the case of an anticipated failure? You don't have to use exceptions for that.
      - formerly_proven 5y ago
        Because that's highly un-idiomatic in pretty much every language that has exceptions, except G++, which arguably doesn't really have exceptions as they are strengstens verboten. Even if you really really like error return codes and really really don't like exceptions, you'll likely agree that writing very un-idiomatic code that goes against the grain of the language and all the libraries you might be using is likely a much bigger loss than the value you might have added by avoiding exceptions in your part of the block.
        Veuxdo 5y ago
        It's really comes down to wether you think exceptions are an everyday thing not. I like going by the dictionary definition of the word "exception" which states that they are not. Out of curiosity, in what languages are error return types non-idiomatic?
        slaymaker1907 5y ago
        Python and Java are two that come to mind. It is idiomatic in both to return null/None on error, but it is not idiomatic to use a result type. Hell, Python even uses exceptions to terminate iterators. This isn't to say the idioms are never broken or that they shouldn't be broken. I agree that if you are doing something like parsing a string to an integer, that should probably be a result type and not just throw an exception.
  - jjnoakes 5y ago
    Depends on the language and library. But even for exceptional exceptions, you may still want or need to retry or branch based on what was thrown.
  - cortesoft 5y ago
    How frequently does it have to occur to be normal? 50% of the time? 5%? .005%?
- konschubert 5y ago
  That, or a count metric.
- chousuke 5y ago
  I think errors and failures get often conflated. There are truly exceptional situations where your application can do nothing and will just have to abort (passing off the failure to a higher layer in the system) but often failures aren't really exceptional. You can not assume that your database connections live forever, for example, and it's not an error when a commit fails due to an interrupted network connection. Such cases need to be handled. If you know that an operation is unreliable, you need to add retry / recovery logic and perhaps log or increment a metric that you can track what's going on; a high number of failures often indicates an exceptional situation. In some cases, your retry logic will be a "Please try again" message to the user. I think that's perfectly acceptable, but you'll still want to know about it.
fuzzy2 5y ago
Not really a point I read in TFA but I agree. Catching just to log something is generally wrong.
- simion314 5y ago
  > Catching just to log something is generally wrong Yes, but you should catch as soon as possible (or validate stuff as soon ass possible) and re-throw with a better error message if possible. You will thank yourself when some problem appears and instead of a random "errorcode 123" you get a detailed message like "Operation Xyz failed with errorcode 123";
vanusa 5y ago
I think what the post is trying to say is that you should let your exception bubble up. Usually, but not always. That is, for the classic "exceptions should only be used in exceptional cases" scenario, this is usually what you want to do. A good portion of the time, though, this scenario doesn't apply. You're dealing with a subsystem that is throwing an exception (for good reasons or bad) but no, you don't want to just the application crash. You want to ... catch it, and do something else. Which is what try-catch was devised for in the first place, after all.
KallDrexx 5y ago
> I think what the post is trying to say is that you should let your exception bubble up. It's not an either-or situation though. Even if you let the exception bubble up and sentry logs the exception, logging performed prior to the exception and at the time the exception is caught (prior to being bubbled up) as valuable context to how the exception happens, which can lower debugging time. The exception just tells you that something went done, it doesn't always have the reason why something went wrong. And the context for why is not always available at the time of raising the exception (the context may be from a prior function call, or the consumer of the function that raised the exception).
ninkendo 5y ago
Eh... a lot of this article can be reworded as "do error handling better" (make error paths unreachable through your type system, crash for unrecoverable errors, if errors are recoverable, they should be Results, etc etc.) Ok, I did all that. And I still want to know why this bug report happened, and logs help me. Why should I Not Log?

masklinn 5y ago

That, however, does not at all work when exceptions are part of the "normal" process and should be ignored or cleanly retried (having spent a while interacting with github, if you take the entire thing down every time github replies with an error and log that to sentry, your sentry instance will last all of 5mn before you have to declare bankruptcy or just plonk the alters and ignore everything). But in that case you probably still want to know about these failures, so you can review them from time to time, or see if there are upticks in failure frequency.

Veuxdo 5y ago
Exceptions should not be normal by definition.
- deleted 5y ago
  [deleted]
- contravariant 5y ago
  With some systems I have indeed been tempted a few times to only throw an exception if everything went right in one try, but my suggestions have been rejected so far.
- mkohlmyr 5y ago
  That's a wonderful theory. I have a third party which returns errors ~20% of the time outside of working hours (yes, really). 1. Exceptions should be sent to sentry. 2. Exceptions should not be normal. 3. Do not log. Solve for ability to review & debug after the fact.
  - Veuxdo 5y ago
    If it doesn't work that often, then it isn't an expectation. That's just how it works.
  - frenchyatwork 5y ago
    > I have a third party which returns errors ~20% of the time outside of working hours Then presumably those errors shouldn't be exceptions. Of course, there's a lot of a lot of assumptions behind this: 1. You have control over the code that interfaces with the third party. Otherwise presumably you'd have to write a shim that catches the exception and turns it into an error value, and that's probably not worth the effort. 2. You're work in a language that doesn't type check exceptions (i.e. not Java with checked exceptions) and your language also doesn't have a nicer way of handling errors as a (discriminated) union. 3. Your co-workers will go complete bananas if you start using some sort of result type or [success, value|error] tuple instead of an exception because that's how they've done it for 20 years. The reason for this is that exceptions in most languages escape the type system and are in general more awkward to catch. Of course, I'd also disagree with "do not log" in this context, though I might prefer a logging mechanism that allowed me to write queries on it (like recording values in a database).
    - marcosdumay 5y ago
      Well, unless it's reasonable for your own software to fail the same 20% of the time (well, more, but knowing how much more requires more information) when outside of working hours, you will always need a shim anyway.
- chousuke 5y ago
  In some languages, the standard way to signal failure is to throw an exception. You can't really define exceptions as abnormal in those cases, because failures are part of normal operation; you can't expect them not to happen if you want robust software.
  - Veuxdo 5y ago
    Why not return an error in the case of an anticipated failure? You don't have to use exceptions for that.
    - formerly_proven 5y ago
      Because that's highly un-idiomatic in pretty much every language that has exceptions, except G++, which arguably doesn't really have exceptions as they are strengstens verboten. Even if you really really like error return codes and really really don't like exceptions, you'll likely agree that writing very un-idiomatic code that goes against the grain of the language and all the libraries you might be using is likely a much bigger loss than the value you might have added by avoiding exceptions in your part of the block.
      - Veuxdo 5y ago
        It's really comes down to wether you think exceptions are an everyday thing not. I like going by the dictionary definition of the word "exception" which states that they are not. Out of curiosity, in what languages are error return types non-idiomatic?
        slaymaker1907 5y ago
        Python and Java are two that come to mind. It is idiomatic in both to return null/None on error, but it is not idiomatic to use a result type. Hell, Python even uses exceptions to terminate iterators. This isn't to say the idioms are never broken or that they shouldn't be broken. I agree that if you are doing something like parsing a string to an integer, that should probably be a result type and not just throw an exception.
- jjnoakes 5y ago
  Depends on the language and library. But even for exceptional exceptions, you may still want or need to retry or branch based on what was thrown.
- cortesoft 5y ago
  How frequently does it have to occur to be normal? 50% of the time? 5%? .005%?
konschubert 5y ago
That, or a count metric.
chousuke 5y ago
I think errors and failures get often conflated. There are truly exceptional situations where your application can do nothing and will just have to abort (passing off the failure to a higher layer in the system) but often failures aren't really exceptional. You can not assume that your database connections live forever, for example, and it's not an error when a commit fails due to an interrupted network connection. Such cases need to be handled. If you know that an operation is unreliable, you need to add retry / recovery logic and perhaps log or increment a metric that you can track what's going on; a high number of failures often indicates an exceptional situation. In some cases, your retry logic will be a "Please try again" message to the user. I think that's perfectly acceptable, but you'll still want to know about it.

fuzzy2 5y ago

Not really a point I read in TFA but I agree. Catching just to log something is generally wrong.

simion314 5y ago
> Catching just to log something is generally wrong Yes, but you should catch as soon as possible (or validate stuff as soon ass possible) and re-throw with a better error message if possible. You will thank yourself when some problem appears and instead of a random "errorcode 123" you get a detailed message like "Operation Xyz failed with errorcode 123";

vanusa 5y ago

I think what the post is trying to say is that you should let your exception bubble up. Usually, but not always. That is, for the classic "exceptions should only be used in exceptional cases" scenario, this is usually what you want to do. A good portion of the time, though, this scenario doesn't apply. You're dealing with a subsystem that is throwing an exception (for good reasons or bad) but no, you don't want to just the application crash. You want to ... catch it, and do something else. Which is what try-catch was devised for in the first place, after all.

KallDrexx 5y ago

> I think what the post is trying to say is that you should let your exception bubble up. It's not an either-or situation though. Even if you let the exception bubble up and sentry logs the exception, logging performed prior to the exception and at the time the exception is caught (prior to being bubbled up) as valuable context to how the exception happens, which can lower debugging time. The exception just tells you that something went done, it doesn't always have the reason why something went wrong. And the context for why is not always available at the time of raising the exception (the context may be from a prior function call, or the consumer of the function that raised the exception).

ninkendo 5y ago

Eh... a lot of this article can be reworded as "do error handling better" (make error paths unreachable through your type system, crash for unrecoverable errors, if errors are recoverable, they should be Results, etc etc.) Ok, I did all that. And I still want to know why this bug report happened, and logs help me. Why should I Not Log?