Re: [boost] Noexcept

Subject: Re: [boost] Noexcept
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2017-06-21 06:32:51

On Tue, Jun 20, 2017 at 4:41 PM, Gavin Lambert via Boost <
boost_at_[hidden]> wrote:

> On 20/06/2017 20:32, Emil Dotchevski wrote:
>
>> On Mon, Jun 19, 2017 at 11:58 PM, Andrzej Krzemienski wrote:
>>
>>> I want to be alerted, and possibly stop what I was
>>> debugging before. This default setting is my friend, provided I do not
>>> use
>>> exceptions for just any "irregularity".
>>>
>>
>> Exceptions are not used in case of "irregularities" but to enforce
>> postconditions. When the program throws, it is in well defined state,
>> working correctly, as if the compiler automatically writes "if" statements
>> to check for errors before it executes any code for which it would be a
>> logic error if control reaches it. The _only_ cost of this goodness is
>> that
>> your code must be exception safe.
>>
>> Programmers who write debuggers that by default break when a C++ exception
>> is thrown likely do not understand the semantic differences between OS
>> exceptions (e.g. segfaults, which *do* indicate logic errors) and C++
>> exceptions. Semantically, that's like breaking, by default, every time a C
>> function returns an error code.
>>
>
> While I don't disagree with that, and I use a debugger which by default
> does not pause on caught exceptions, I tend to run it configured to pause
> on all thrown exceptions regardless.
>
> This is because in the codebases I tend to work with, exceptions are rare
> and unusual and generally indicative of a serious problem in either the
> code or the input, and thus they ought to be investigated whenever they
> happen, because they're not supposed to ever happen.
>
> As a result, code that throws exceptions for other reasons irritates me,
> and I try to avoid using it.
>

The "serious problem" classification is not exactly tangible. :) And,
presumably you need to handle other errors that aren't "serious problems",
and you don't want to use exceptions in that case (why?), so what do you do?

In my book, if returning from a function would leave the caller in a state
that requires it to abandon what it was doing and in turn return to its
caller, there is seldom a reason to insist on writing that if statement
manually; and this rarely requires special attention in the debugger.

Even where I might normally run without that enabled, at some point I find
> myself needing to track down a logged exception, so I turn it on, and then
> get irritated if exceptions other than the one I was looking for turn up.
> So again it's preferable to not have them happen unless they're serious.
>

I'd say that it's preferable to use a debugger which can break on some
exception types but not others. :)