[OT] - C++ exceptions are becoming more and more problematic

[H. S. Teoh]

On Thu, Feb 24, 2022 at 02:42:14PM -0800, Walter Bright via Digitalmars-d wrote:
> On 2/24/2022 12:01 PM, H. S. Teoh wrote:
> > The problem with replacing exceptions with return codes is that it
> > requires writing tons of boilerplate to handle error codes.
> 
> I specifically said not using return codes, and gave examples.

It amounts to the same thing: the caller must explicitly handle all
error conditions. This is cumbersome and incentivises people to ignore
error conditions or just sweep it under the rug.  And often, the caller
simply isn't in the position to decide how to handle the error condition
(for example, whether a particular error condition is fatal or not
depends on contextual information that's only available further up the
call stack).

More specifically: making failure a valid part of your return type
requires that your callers explicitly check for this failure. It's just
a paraphrasis of `if ((ret = func(...)) != OK) goto EXIT;`. Explicit
checking is a good idea in some cases, but in other cases introduces
unacceptable amounts of boilerplate, such as when every function call in
a long list of function calls must be wrapped around `if (error) goto
EXIT;` boilerplate.

Also, redesigning the problem like using the replacement character on
invalid UTF-8 does not always make sense.  Sometimes you *want* your
code to abort upon failure rather than silently substitute a nonce value
in your data. E.g., if you're deep inside some parsing function and
encounter a UTF-8 encoding problem, you do not want it to just insert
some replacement data that isn't part of the input stream; you want it
to bail out and abort the entire operation with a proper error message.


T

-- 
Marketing: the art of convincing people to pay for what they didn't need before which you fail to deliver after.