[mkohlmyr]

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.

[frenchyatwork]

> 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]

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.

[Veuxdo]

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