Comparing Exceptions and Errors in D

I think the reason the documentation is cryptic is because it's a library-supplied User Data Attribute that is specially recognized by the compiler. The documentation generator is having trouble with it. In code it's pretty simple:

https://github.com/dlang/druntime/blob/705fb36e5fc4d930eed85...

mhh__2• 4 years ago

@mustUse is a user defined attribute the compiler recognizes that forces return values it affects to be used.

e.g. if you return something that could contain an error then ignoring the return value could be disastrous.

loeg3• 4 years ago

A similar concept is used widely in glibc under the name “__wur” (shorthand for __attribute__((warn_unused_result))).

https://github.com/bminor/glibc/search?q=__wur&type=

giancarlostoro3• 4 years ago

I kind of get this much, but it would be nice to see a small set of code showcasing this in practice to really cement it in for me.

simcop2387• 4 years ago

If you want to look at it from an academic perspective it tells the compiler that it should be a relevant[1] type. The idea is that you can make the compiler force the use of the value at least once. This is great for error or result types so that you can require the caller of your code actually check for an error or valid result, this way you can't forget to do it (if you do it's a compile error and you never get to run the code).

[1] https://en.wikipedia.org/wiki/Substructural_type_system#Diff...

Doxin2• 4 years ago

It'll throw an error for

    myFunc();

but not for

    auto foo = myFunc();

if myFunc returns a mustUse type.

giancarlostoro3• 4 years ago

Thank you, I know it looks stupid simple but code helps me put it into a perspective I can remember better vs only reading documentation about code. That is kind of an interesting way to sort of force someone to not just throw away a return value.

Question: Do you know if this would also be fine if the called function was in a return statement?

twic3• 4 years ago

However, a nothrow function is still allowed to throw an Error. How does that work?
How it works is that the compiler still omits exception cleanup code, and the code that catches the Error is not allowed to continue the program. If it does, the program may obviously be in an invalid state.

Yikes? What's the rationale for allowing errors to be thrown out of nothrow functions, rather than just aborting there and then?

schveiguy2• 4 years ago

The rationale is that in a correctly written program, an Error should never be thrown. It's similar to UB in C. The compiler can assume Errors are never thrown, and so it can not worry about cleanup in nothrow functions.

But the nice thing is, it reuses the same handling mechanisms as exceptions. You don't have to create something different for handling Errors. In fact, the code that prints error stack traces and exits is the same code that handles exceptions.

Consequently, this is why you shouldn't catch them, or at least not catch them and continue. The exceptions are unittests and contract asserts, where the compiler does guarantee proper stack unwinding.

colejohnson66• 4 years ago

If I understand, a throw in a nothrow would be used for completely unrecoverable situations? Akin to Rust’s panic!() macro?

twic3• 4 years ago

The rationale is that in a correctly written program, an Error should never be thrown. [...] you shouldn't catch them, or at least not catch them and continue

In that case, why not just abort? Why give the user a footgun like this?

arunc2• 4 years ago

A nothrow function can throw? WTH.

Comparing Exceptions and Errors in D

Related Stories