During the last beerconf, I wrote a short blog post about how Error and Exception are different, and why you should never continue after catching Errors.

Feedback welcome, I didn't announce here when I wrote it because it's kind of small/insignificant, but maybe it can help newcomers to the language: https://www.schveiguy.com/blog/2022/05/comparing-exceptions-and-errors-in-d/

-Steve

On 6/3/22 8:44 PM, Ali Çehreli wrote:

Yes, the one exception to the no-catch error rule is to print/log diagnostic information. But you should never continue executing after that.

If a thread does not catch an error and end the program, that's a defect in druntime I think. If it tries to rethrow the exception in the main thread (oh, man I have to check... Yeah, this is what it does), then it's entirely possible that the main thread will never even get to the Error!

Yes, that is what it should do.

It's useful to do something, so it's not just an empty log file with no idea where the error occurred.

I've thought in the past that throwing an error really should not throw, but log the error (including the call stack), and then exit without even attempting to unwind the stack. But code at least expects an attempt to throw the Error up the stack, so code that is expecting to catch it would break.

-Steve

On Friday, 3 June 2022 at 23:40:50 UTC, Steven Schveighoffer wrote:

Here my feedback:

1. What if div is called with x = -2147483648 and y = -1? Isn't code
   which allows a divisor == 0 to propagate to the CPU an error? Must
   the code thus not throw an object instantiated from a subclass of Error?

   What if I have that function div used in code which is called from say
   controller code of a CGI binary. Or likewise from a vibe.d-thread servicing
   a web request? How do I isolate that fault? Do I have to spawn a subprocess
   as Walter suggested in the case of memory corruption [1]?

   [This is of course all rhetorical!]

2. Since 2017 or so I have written some 10 KLOC of D, maybe about two dozen
   classes deriving from Exception. But I did not annotate any of my methods or
   function with "nothrow" nor did I author any class deriving from Error.

   What does that mean? Am I Error blind?

3. Can you provide some piece of code which must throw Error and cannot
   throw an appropriate Exception?

[1] http://forum.dlang.org/post/t6ef8c$1cu5$1@digitalmars.com
Re: Why is D unpopular?

On Saturday, 4 June 2022 at 11:57:32 UTC, kdevel wrote:

Generally you do not need to subclass Error yourself. The most common way of throwing an Error in user code is to use assert, which (with default compiler flags) throws an AssertError on failure. Function contracts and struct/class invariants work the same way.

This is entirely a question of API design. If it should be the caller's responsibility to check for some condition before calling the function, then you can throw an Error when that condition does not hold (or more likely, use an assert or an in contract to check for it). If it should be the callee's responsibility to check, you should throw an Exception (or use enforce).

On Saturday, 4 June 2022 at 01:17:28 UTC, Steven Schveighoffer wrote:

This is too harsh for a service that is read-only, meaning a service that only read from a database and never writes to it. All running threads have to be given a chance to exit gracefully, at the very minimum.

What is the source for these errors anyway? A filesystem not responding? A crashed device driver? A race condition? A deadlock? Starvation? Many sources for errors can be recovered from by rescheduling in a different order at a different time.

What I'd like to see is a fault tolerant 100% @safe actor pattern with local per-actor GC. By fault tolerant I mean that the actor is killed and then a new actor is rescheduled (could be an alternative "reference" implementation or the same after a time delay).

Also, what it is the purpose of @safe if you have to kill all threads? Such rigidity will just make Go look all the more attractive for service providers!

On 6/4/22 7:57 AM, kdevel wrote:

Well, that is just a toy example to show code that might use an Error. It's not intended to be a fully-fleshed-out function. I recommend simply using the divide operator in real code.

The point of an Error is that your code can assume it cannot happen. If it does happen, the code is invalid. This is reflected in the fact that the compiler will omit cleanup code if an Error is thrown (it can assume that it will never happen). The point of using Error is for a last resort check for program correctness (because you failed to validate the input before getting to that point).

vibe should exit the process if an Error is thrown. There is a version you can specify to have it catch Error, but it would only be for debugging. https://vibed.org/docs#compile-time-configuration (see VibeDebugCatchAll)

One thing that always bugs me in my vibe code is out of bounds errors for arrays. I actually replaced some arrays with an Exception throwing wrapper because I didn't want to crash the whole server for certain cases, and I didn't want to continuously validate array indexes.

As long as you aren't catching Throwable or Error, you should be fine. Simply not marking things nothrow doesn't mean that they won't be inferred nothrow. auto and template functions are inferred.

In practice, there are probably very very few places where this can bite you. Which also means, if it does bite, it's going to be really really hard to track down.

As Paul said, this is up to your API. If you specify that you assume the inputs to the function are cleansed, then you can correctly throw an Error if they are out of spec.

A great example are range functions. Often times you see at the beginning of any popFront method the statement assert(!empty);. This is universally accepted, as you shouldn't be calling popFront if you haven't checked for empty.

-Steve

On Saturday, 4 June 2022 at 14:19:22 UTC, Ola Fosheim Grøstad wrote:

I agree with this, but given the current semantics there is nothing else to do but teardown everything upon first sight of Error.

The reasoning is simple: Error + nothrow will sidestep any RAII you may have. Since you cannot know what potentially wasn't destructed, the only safe course of action is to abandon ship.

Yes, in plenty of cases that is completely overkill.

Then again, programs should be written to not assert in the first place.

Considering most asserts I have seen are either due to a bad api or just laziness - and shouldn't have to exist in the first place - maybe it's not that bad.

On Saturday, 4 June 2022 at 01:17:28 UTC, Steven Schveighoffer wrote:

Yes, for that reason, and others, people should not use that api.

Probably yes.