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

Dave via Digitalmars-d digitalmars-d at puremagic.com
Thu Jun 11 14:57:36 PDT 2015


> He is saying that now anything that throws will not only be 
> slow but also have the same limitations as returned errors.

"nothrow by default is combining the slowness of exceptions with
the limitness of returned errors."

He literally said combine the slowness of exceptions. So I don't
know how to read that other than he said it's slow. But perhaps I
am just misunderstanding his wording, so perhaps it's best I just
assume I misunderstood him.

> but also have the same limitations as returned errors

That is a legitimate concern, but I don't think it is correct.
The transitive nature would enforce that you at least handle it
at some point along the chain. Nothing would force you to handle
it right away. Although I think in most cases it's far better to
do it when the error occurs(but this is my style). But when you
don't there would be at least a flag saying "this might fail"
that you and others could see. You can ignore that all the way up
the turtles, but at some point you are going to be like "I should
handle these errors".

> If you have to acknowledge it anyways, then might as well just 
> use returned errors because they are faster.

I guess you could think of nothrow as an acknowledgement. I'd
view it more like a warning to others. As I said before, I don't
think you should be *forced* to do anything. Handle it right away
and you don't have to mark your own function as 'throw'. Don't
handle it, then your function should be marked 'throw', and the
compiler can help others out and tell them to expect to have to
handle the exception at some point.

In regards to being faster, I'm not a big fan of exceptions in
the first place. This probably explains my perspective on them,
but I am familiar with their typical use case. And it's to
communicate errors. I'd much prefer something like what Andrei
presented during one of his C++ talks (Expected<T>). If I were to
design a language today, I might try to incorporate that somehow
with some semantic sugar and a "handle by default" mentality.


More information about the Digitalmars-d mailing list