Unreachable exception?

[plajjan]

I'm writing a bunch of code that is essentially unreachable, or at least should be unreachable and I wonder if it would be helpful to have an exception that more clearly reflects this use. In Zig there is a unreachable that can be used to this exact effect.

raise ValueError() feels like "there was something wrong with the value", but saying raise Unreachable() is more like "there was something wrong with the value and that should never happen because some other part of our program should ensure this value is always valid". See the difference?

wdyt @nordlander ?

[nordlander]

Sounds reasonable. And it's easy to extend the Exception hierarchy, just inherit class Exception. So I guess the only issue is whether the new class should be in builtin. Which sounds reasonable too, I think.

[plajjan]

This is effectively a way for the developer that raises the exception to indicate some intent behind it, like this code should really never be hit. It is indicative of a bug, and not just some slightly wrong input parsing somewhere. But what do we do about it? Zig's unreachable will immediately exit the program. For development builds, I quite like that approach.

Its placement in the exception hierarchy and if we have built-in treatment of it is perhaps what would really set it apart.

Python programmers quite casually do try / except. I don't really want to encourage that in Acton, but it is the simplest code to write. I feel that the semantics of an Unreachable should be that it is not just catcheable, again, at least for dev builds. Since we have an aspiration for always-on systems in prod, I'm not sure what should happen there.

A somewhat similar topic is how out-of-memory exceptions. With a distributed RTS we could automatically retry such failures by migrating an actor to another node. It is similar in that it is challenging to place the exception properly in the hierarchy and potentially have some automatic RTS remedy in some cases but not in others.