Date: Wed, 23 Oct 2019 10:38:20 -0400
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
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0709r4.pdf> 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.)
–Arthur
On Tue, Oct 22, 2019 at 2:01 PM Sophia Poirier via Std-Proposals <
std-proposals_at_[hidden]> 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 <
> std-proposals_at_[hidden]> 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
> <https://www.reddit.com/r/cpp/comments/cliw5j/should_not_exceptions_be_finally_deprecated/>
> .
>
>
- 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
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0709r4.pdf> 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.)
–Arthur
On Tue, Oct 22, 2019 at 2:01 PM Sophia Poirier via Std-Proposals <
std-proposals_at_[hidden]> 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 <
> std-proposals_at_[hidden]> 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
> <https://www.reddit.com/r/cpp/comments/cliw5j/should_not_exceptions_be_finally_deprecated/>
> .
>
>
Received on 2019-10-23 09:40:47