Just saw this today:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2544r0.html

Seems relevant to any System Language like D that features Exceptions.

Matheus.

I'm kinda in agreement with Herb's proposal for C++ but for D.

Runtime exceptions are expensive and not worth it for _alternative results_ which is where we kinda need them and without them things get messy...

As a result this is kinda something I would to have in D. The sort of thing I was thinking for D:


Support struct based exceptions (value type), passed on stack (and hence RC support) as part of the return value of a function.

Add a new attribute ``throws``. It should include types that say what will be thrown.

``@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.

A function must either explicitly include or inherit all functions it calls throwable types. Unless it catches them (for classes that would include parents i.e. Throwable would remove all of them).


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.

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. This means that the compiler must give an error when the exception was thrown which wasn't declared. Also warn about exceptions not thrown when they are declared so the compiler must track the exceptions anyway. Let the compiler do it, that's what computers are for. Also let's be conservative with @badging.


> 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.

On 24/02/2022 5:20 AM, IGotD- wrote:
> 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. This means that the compiler must give an error when the exception was thrown which wasn't declared. Also warn about exceptions not thrown when they are declared so the compiler must track the exceptions anyway. Let the compiler do it, that's what computers are for. Also let's be conservative with @badging.

Okay that is easily rectified, we simply allow inheriting from the function body, not just called functions ;)

The reason it must support be declared in some form (which is how it is also represented in the AST) is due to it being value type. Its like as if you put a algebraic type for the return value with your declared return value + what can be thrown from it.

On Wed, Feb 23, 2022 at 02:26:41PM +0000, matheus via Digitalmars-d wrote:
> Just saw this today:
> 
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2544r0.html
> 
> Seems relevant to any System Language like D that features Exceptions.
[...]

Quote:

	"The root cause is that the unwinder grabs a global mutex to
	protect the unwinding tables from concurrent changes from shared
	libraries. This has disastrous performance implications on
	today’s and upcoming machines."

Does D's unwinder grab a global mutex?


T

-- 
He who sacrifices functionality for ease of use, loses both and deserves neither. -- Slashdotter

On Wednesday, 23 February 2022 at 16:20:43 UTC, IGotD- wrote:
> 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.

Then don't use exceptions for performance reasons. Leave it alone for other people who don't care about performance.

-Alex

On Wednesday, 23 February 2022 at 16:52:21 UTC, 12345swordy wrote:
>
> Then don't use exceptions for performance reasons. Leave it alone for other people who don't care about performance.
>
> -Alex

I don't exceptions would be removed ever, either from C++ or D because that would break a lot of existing C++/D code.

The Herb Sutter exception/return value proposal would live alongside with the old exceptions. I suspect that D would do the same thing.

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.

On 24/02/2022 5:59 AM, IGotD- wrote:
> The Herb Sutter exception/return value proposal would live alongside with the old exceptions. I suspect that D would do the same thing.

Yes, with the possibility of having the compiler swap the runtime unwinding stuff for value based where possible.

Apart from some situations where you need to be able to store a class based exception, I don't see why it couldn't work like this.

On 24/02/2022 6:02 AM, H. S. Teoh wrote:
> 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.

Not quite.

You don't have to write @throws in the majority. It would be inferred automatically (only function pointers).

How it is represented in the AST and how the di generator will generate code should be simple like this. But most developers shouldn't have to touch the attribute even for the main function.

So in practice this should be more similar to our experience with nothrow and @safe/trusted/system rather than Java's.