The promise of exceptions isn't to not have to specifically handle errors in every layer
Correct me if I am wrong, but aren't exceptions in D used for general error handling? Doesn't Phobos prefer exceptions over return codes?
it's to not care about exceptions in every layer.
My second job was working in the sustaining department of a large company. One of the most frequent cause of bugs were people not checking errors. The fix was almost always handle the error at its source and log or signal a message to some IO informing the user. Users tend to prefer messages over complete meltdowns. Too many avoidable outages and crashes came by my desk due to this attitude. Very few domains/cases require hard fails.
I don't want to pass the annotation in each and every intermediate layer
Seems like an odd comment to have on the forum of a language that frequently has functions in the standard library annotated like this: pure nothrow @nogc @safe real abs(Num)(Num y)
The middle layers should be written like there is no exception, and when there is one, they will simply fail and let RAII to automatically do the cleanup.
Everything works better than expect...
I've programmed enough Java to know how harmful nothrow-by-default is.
I disagree one this. Lets agree to disagree.
It doesn't really guarantee the functions not annotated as throwing won't > crash
Combined with other guarantees (such as immutability, thread local storage, safe memory management, side-effect free code, no recursion, etc), you can make a reasonable guarantee about the safety of your code.
Of course, nothrow as the optional annotation is a different syntax for the same semantics, so it suffers from the same drawbacks but it has the benefit of seldom being use therefore seldom getting in your way. Which leads me to the final conclusion - there shouldn't be nothrow, not by default and not as special annotation!
The guarantee is useful in many cases. Again lets agree to disagree. But I agree most people will "opt-out".
(I'm not talking about D here - this isn't worth the code breakage - but generally on programming languages)
As am I. My initial comment was not meant to encourage change in the D language. But perhaps it may spin the right dials on someone else and they may think of a better fitting solution.
If it's an error that the caller needs to know about - make it part of the return type. If it doesn't need to know about it - throw an exception and let someone up the line handle it.
I don't agree with this. Too much to worry about. Impractical to maintain both paradigms. What errors don't you need to know about?
Rust got it right - though they made it a bit cumbersome to catch `panic`s. Why would I need to catch panic? To display them nicely to the user(don't just dump to stderr - pop up a window that apologizes and prompts the user to email the exception data to the developers) or to rollback the changes(yes, there was an irrecoverable error in the program.
I am not anywhere near proficient enough in Rust to really comment much on it's methods.
handle it or ignore it.
The process I mentioned would not prevent this in anyway. Just inform others of the decision you made that may have adverse effects on the stability of their code.
