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

[Idan Arye via Digitalmars-d]

On Thursday, 11 June 2015 at 00:27:09 UTC, Dave wrote:
>> 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 seems to be a controversial subject: 
https://github.com/D-Programming-Language/phobos/pull/1090#issuecomment-12737986

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

Exceptions are not meant to force handling errors at he source. 
If you want to force handling errors at the source they should be 
part of the return type. I'm not talking about C style 
return-error-code-and-write-the-actual-result-into-a-variable-passed-by-reference 
- functional languages like Haskell, Scala and Rust have shown 
that monadic sum types of result/error are both safe(don't allow 
you to access the returned value unless you do it in a path that 
makes sure there wasn't an error, or convert the error into an 
exception) and easy to use(adds very little syntactic overhead 
for the good path, and the bad path code is simpler than in 
exception handling)

Exceptions are not "hard fails". You don't have to crash the 
entire program - just fail the action the user was trying to do 
and display a nice error message with whatever information you 
can and want to provide to the user. Even if you don't handle 
them, they provide information useful for debugging.

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

Just because I use the language doesn't mean I have to like every 
single one of it's features...

>> I've programmed enough Java to know how harmful 
>> nothrow-by-default is.
>
> I disagree one this. Lets agree to disagree.

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

And a superhero cape, combined with an airplane, airplane fuel 
and flight school, allow you to fly in the air.

It is the other restrictions(without getting into a discussion 
about each and every restriction in the list) that make the code 
safer - nothrow doesn't really contribute IMO.

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

Scala and Rust seem to maintain both paradigms just fine. It's 
actually beneficial to have both - you have to acknowledge 
return-type-based exceptions, and you can always bypass them by 
turning them to exceptions, which are good for logging and 
debugging. If exception handling is enforced, they can only by 
bypassed by converting them to errors or crashes, which are much 
less nice than exceptions when it comes to debugging, logging and 
cleanup.

If I have to be explicit about not handling an error somewhere, I 
prefer the "this exact thing here can return an error, I assume 
it won't, but if it does you'll get an exception so it can be 
debugged" approach over the "not that I care, but something, 
somewhere down that path might throw" approach.

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

Writing code that acknowledges that this code can fail due to an 
exception somewhere else does not count as ignoring it.