Yes. I think it's important to recognize that both complaints are valid:
- Traditional EH introduces invisible control flow
- Traditional EH introduces performance penalties on the slow path, and code bloat in general

I know that Herb Sutter recognizes both complaints. IMO the "Herbceptions" proposal so far deals mainly with the second (performance) issue. Herb's P0709R4 Section 4.5.1 does weakly suggest a `try foo()` syntax to make the invisible control flow more visible; but I don't think that feature is very much thought-out or baked. The paper shows an EWG straw poll from Cologne indicating that further work in that specific direction is discouraged.  However, EWG (and certainly Herb) are aware of the problem.  There's no solution yet, but that just means we need more time to think and — especially — to experiment in real codebases and see what works and what doesn't.

(Furthermore, I think that C++2a [and C++2b] should be delayed.)


On Tue, Oct 22, 2019 at 2:01 PM Sophia Poirier via Std-Proposals <> wrote:
I work in industries with realtime-sensitivity where turning exceptions off is common and always due to the performance overhead.
On Oct 22, 2019, at 1:23 AM, Dmitry via Std-Proposals <> wrote:

I, personally, think that a lot of people are "fighting a strawman", trying to address wrong questions.

The main problem with exceptions (and therefore, the reason why they are banned) is not overhead, but their "implicit-ness".
People want to understand what is going on (I mean, is it possible to have an error in this particular function or not, and which error exactly) without having to recall each line in the entire codebase, but rather by looking on the signature of a function.
The property of locality if very important - that is exactly what OOP is about - being able to reason about code, without having to remember distant part of codebase is crucial. Herb's exceptions do not do much in this regard...

I have already posted here my take on the topic, but in case you missed it, here it is.