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

[H. S. Teoh]

On Wed, Feb 23, 2022 at 04:20:43PM +0000, IGotD- via Digitalmars-d wrote:
> On Wednesday, 23 February 2022 at 16:11:45 UTC, rikki cattermole wrote:
> > 
> > ``@throws(Exception)`` would be equivalent to what D functions without
> > ``nothrow`` are today by default. ``@throws()`` would be equivalent to
> > ``nothrow``.
> > 
> > ``@throws(Struct)`` would only allow the Struct to be thrown from a
> > function.
> > 
> 
> I'm really against "manually" declaring which exceptions a function
> throws.  It will quickly become unmaintainable as people will forget
> which exceptions that are thrown and which are not.

Yeah, this is just another variation on Java's checked exceptions, which
experience has proven is not worth the trouble, because people find it
too cumbersome and either don't use it or just slap on boilerplate like
`throws(Exception)` just to make the compiler shut up, which defeats the
whole purpose.


[...]
> > I would like to hear other opinions especially Walter's since I
> > don't think he has commented on value type exceptions design-wise
> > recently.
> 
> Walter said that exceptions are on the way out, because of the
> optimization problem which this article also described. He has not
> presented an alternative error handling mechanism.

The problem described in this article doesn't seem to be the same
problem as Walter mentioned in the past. The problem here is primarily
caused by contention on a global mutex used by the stack unwinder; I
don't know if the D implementation actually has this problem.

The problem Walter mentioned in the past is more with how it interacts
with the optimizer: once a set of functions may throw, the optimizer can
no longer assume linear control flow through the code that calls these
functions, so it cannot apply optimizations like reordering code, and
data flow analysis becomes a lot hairier.


T

-- 
If creativity is stifled by rigid discipline, then it is not true creativity.