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
