[AnimalMuppet]

> ...because if they did, they might realize that some of their favorite structures are a hot mess.

They may only be a hot mess when expressed as a flowchart. But so what? I'm not programming in flowcharts. If exceptions can do what I want cleanly, why do I care if it's a mess considered as a flowchart? That's not my problem.

This argument is like saying that the library function I call is a mess of a flowchart. Why should I care? Can I express what I need to express cleanly by calling that function, or not?

Of all the arguments against exceptions, "it's got a mess of a flowchart" is the absolutely least relevant one.

[throwaway17_17]

The flow charts in the link represent control flow. Compiler optimizations are, in part, constrained by their ability to map and statically determine control flow. So I think it is a grave mistake to say that something having a ‘mess of a flowchart’ is the least relevant concern about some PL construct. The implication that a flowchart representation offers nothing to a programmer, implies that the performance characteristics of your code does matter to the programmer. So sure, in some application domains (although I don’t think there are any) performance may take a backseat to performance and efficiency, this information is useful and can very well illustrate the pitfalls and trade offs of using certain constructs in code.

[AnimalMuppet]

I'm pretty much never worried about the performance of the "exception taken" case. The compiler can be really quite inefficient there before I have any reason to care.

There are places to worry about compiler efficiency. I don't think that this is one of them.

[zozbot234]

Statically determining data flow is just as important, since it means being able to parallelize your code. Flowcharts are a very limited tool, other diagramming approaches (such as proof nets) can generalize on them in a helpful way.