Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?

[Dave via Digitalmars-d]

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