[carapace]

> Exceptions are rather easy to reason in the code

In some code, for some people.

> their flow chart looks like a hot mess

In code where the "exceptions are rather easy to reason" about the flowchart would also be easy to read.

In code where the exceptions hide a flowchart that's a hot mess the exception syntactic sugar hides the mess.

[airstrike]

One could argue hiding the mess is the whole point of the exception. It allows you think about the problem with a much smaller cognitive load.

I'm not suggesting every code with exceptions is good. Just saying that not every exception is bad, and many are indeed great.

I can't imagine writing Python without try blocks...

[carapace]

Describing the mess in a not-messy way is the whole point of exceptions. If you have a mess in your code either clean it up or document it, don't hide it.

- - - -

Sometimes the problem you're solving really does require a gnarly flow-chart. If that's the case, you're almost certainly better off writing (and documenting!) a state machine instead.

If your control-flow graph is only a little gnarly then representing it with exception syntax is fine IMO (I write Python code too, with exceptions.)

The problem comes when you accidentally create a hidden gnarly graph (as the result of bad design up front, or "drift" over time as a piece of code gets reworked, maybe by multiple people who may not all be privy to the whole history of the design and code, or both) and then forget to do something crucial along some flow of control and you have a hard-to-debug bug.

[notacoward]

> I can't imagine writing Python without try blocks...

In other words, Python requires that model, but making something necessary isn't the same as it being good. If you go around breaking people's arms then splints and casts become necessary. Does that make arm-breaking OK?

> It allows you think about the problem with a much smaller cognitive load.

There's a very fine line between "smaller cognitive load" and "sweeping stuff under the rug". Since you mentioned Python, I'll point out that a lot of Python code only looks simple because it's incomplete and will fail catastrophically for what should be innocuous errors. Add the proper error handling and it's just as complex as code using an error-return or optional-type model. Often that means even more cognitive load because the happy path and the handlers are in multiple methods/classes/files (especially likely as multiple people hack on code over time).