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.

Exceptions should not be normal by definition.

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.

> 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).

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.

If it doesn't work that often, then it isn't an expectation. That's just how it works.

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.

Why not return an error in the case of an anticipated failure? You don't have to use exceptions for that.

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.

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?

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.

In almost all dynamic languages I know of for example. Way too easy to forget about error handling if you use values. Exceptions at least tend to cause noise.

In languages like Java an Python, you can return error values but because you can also always return nulls, you're just making more trouble for yourself than it's worth avoiding exceptions.

In your code, you don't have to use exceptions to indicate a failure but you still have to catch exceptions thrown by third-party libraries (or their dependencies).

It is not easy to stay away from exceptions if your language supports them.

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.

How frequently does it have to occur to be normal? 50% of the time? 5%? .005%?

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.

That, or a count metric.