Question on @nothrow

[Jonathan M Davis via Digitalmars-d-learn]

On Wednesday, May 31, 2017 08:18:07 Vasileios Anagnostopoulos via 
Digitalmars-d-learn wrote:
> Hi,
>
> after reading various articles bout the "supposed" drawbacks of
> checked exceptions I started to have questions on @nothrow. Why
> there exists and not a @throws annotation enforced by the
> compiler? I understand that people are divided on checked
> exceptions and each side has some valid points. But explicitly
> marking a function as throwing "something" is another subject.
> Why have the dlang community reached to the decision to use
> @nothrow and not a @throws?

Well, if you're not doing checked exceptions, the interesting question is
really what _doesn't_ throw rather than what throws, because if the compiler
knows that a function doesn't throw, it can optimize out the exception
handling mechanisms that are normally required. Also, if nothrow wasn't
there originally (and it probably wasn't), then adding an attribute to
indicate that a function doesn't throw wouldn't have broken any existing
code, whereas adding an attribute to indicate that an exception does throw
would have broken all existing code that used exceptions. Also, given that
exceptions are the normal error-handling mechanism for D, it makes more
sense to allow them by default than to disallow them by default.

Ultimately though, since one is a negation of the other, either an attribute
indicating that a function does throw or one indicating that a function
doesn't throw would work. Logically, they're the same. It's just a question
of which makes more sense as a default and what effect adding the attribute
would have had when it was originally introduced, both of which imply that
nothrow is the better choice, even if it could have gone either way.

Regardless, nothrow is what we have, and there really wouldn't be any
benefit to switching it to throw (or throws or whatever) even if breaking
code weren't a concern.

- Jonathan M Davis