4 ms·

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%?