Errors vs Exceptions, and raise vs throw

[Bill Cox]

Andrew commented on the CL for adding a design rationale for exceptions, noting that maybe we should call all these things errors rather than exceptions, and I think he's right.

I reworked it so that "exceptions" are things like failed assertions, calls to panic, numeric overflow/underflow/divide-by-zero.  These are things that maybe should not be propagated up the stack, but instead have sane default handlers that eventually exit.  Users should be able to override these default handlers.  Instead of "exceptions" being raised, I changed the text to talk about "errors" being thrown, and I think it reads better, but maybe this is my C++ history creating a bias.  However, I do like calling OOM and failed assertions exceptions because they are exceptional, while the things we pass up the stack can be things like InvalidArgument.

WDYT?  Should we go back to try/catch/throw instead of try/except/raise?

[Andrew Wilson]

Re terminology, no, I don't think so.  The same argument, lets-be-similar-to-python holds, I think.

Our "error handling" approach is a simple means to elide messy StatusOr<T> conditional checks everywhere, on the understanding that the compiler will put them back in (or at least something semantically equivalent).  We're not really "throwing" anything: "throw" is used to denote non-local flow, perhaps bounding multiple stack frames in one go (like setjmp/longjmp perhaps) but that's not what we're doing.  I would imagine that "throw" is more akin to what we want to do in a panic.

I don't know why numeric overflow/underflow/divide-by-zero should be treated as exceptions rather than errors.  The fix is usually to surround the call site with conditions that would avoid the problem in the first place.  We might write code like:

  if denominator == 0 { raise <oops>; } else { x = numerator / denominator };

or some such.  Why not just avoid this messiness, and assume that we'll raise an error and let the programmer handle the error at the right place?  I imagine that you could make the same argument for null pointer errors.  None of these seem to me to be panic situations, like OOM, or assertion failures.

--
You received this message because you are subscribed to the Google Groups "Rune language discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rune-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rune-discuss/CAH9QtQHTa_jfj9hY%2BEbsg92bXytzEwmLk5kj96U_AObVyy%2BGoA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

Andrew Wilson

Software Engineer, Android TV Eng Prod