Motivations for exceptions vs panic/recover + algebraic types ?

[adevress]

From the comments on side discussions and from the status of the current implementation, it seems that Hylo is heading to the path of having a proper exception support with throws() semantics and stack unrolling for error report.

I am wondering about the motivations behind this choice considering that many 'new generation' programming languages (Rust, Golang, Odin, Zig) seems to have ditch exceptions for a panic/recover mechanism + algebraic datatypes ( std::Result ).

This topic is generally a bit controversial but from my experiences in large scientific codebases and in the embedded system world, I have a mixed feeling about exceptions.

On the negative side:

• They tend to encourage bad coding practice for young programmers. Mainly because it is easy and tempting to throw() for everything and nothing, including:

  • For preconditions/invariants. Currently even the STL of C++ throw instead of using preconditions with std::logic_error.
  • For error that shall be recoverable / annotated locally. (e.g catch exceptions in the hot path to check that a file does not existing)
  • As a poor man "yield" for values on deep graph hierarchy ( I have seen that: some scientists can be very creative )

• They create an entire new class of problem due to the stack unwind if misused with destructors or with move semantics.

• Most implementations enforce the usage of a runtime to support them. That causes issues for embedded systems or kernel mode programming where a runtime is not acceptable.

• Most existing implementations are currently requiring dynamic allocation and polymorphism which have there own set of problem and are ban from most embedded, realtime and safety critical systems.

• They make the certification much harder in safety critical system due to the explosion of the number of branchings in the code coverage mainly due to the stack unwind.

On the positive side:

• They do make error management much less verbose.

• They are much more convenient for prototyping.

• They do prevent abusing usage of error silencing and pre-conditions.

[dabrahams]

This is the only thing I can interpret as a question above:

I am wondering about the motivations behind this choice

I'll try to respond to that; to the rest, I mostly can only say, "noted!"

Exceptions improve a large category of relatively high-level code that would otherwise include a lot of "check the result to see if it's an error (or a concurrent task cancellation) and if so return it; otherwise unwrap it and continue" boilerplate. Hylo is not trying to be an exclusively-low-level programming language, and that higher-level code is much worse and harder to reason about with the boilerplate included. Also, by distinguishing errors (i.e. postcondition failures) in the language we can improve correctness by making any partially-mutated (and thus meaningless) values inacceessible to the programmer.

Re: “new class of problems:” there's no interaction with Hylo's destructive move semantics, or with Hylo's destructors which are statically-checked to be nonthrowing.

There's no explosion of branching compared to the equivalent boilerplate that exceptions eliminate. Either your code needs that execution pattern or it doesn't; the branching is the same. If the concern is merely about visibility of the branches, tooling can help. In day-to-day programming seeing the branches all the time gets in the way and makes it easier to create bugs. The safety-critical programming community is important but small; I'm willing to tell them to use tools to do their validation if it means general coding is better/easier.

[adevress]

Thank you for the answer !

From informations available on other posts ( #1261 and #1257 ), the discussions seem to go in the direction of a exception design of with static allocation and limited polymorphism, which also eliminate some of the problems I was pointing on here.

[mrael2]

• Most implementations enforce the usage of a runtime to support them. That causes issues for embedded systems or kernel mode programming where a runtime is not acceptable.

Will Hylo's implementation require a runtime?

[dabrahams]

Not in the usual sense. A small “freestanding” library that can probably be entirely inlined and doesn't depend on any OS support (e.g. malloc) is compiled into every hylo program. That's where Int et. al are defined. A “hosted” build depends on OS support and adds some capabilities, like the ability to throw arbitrarily-sized exceptions.

[adevress]

Changed the discussion as Q/A and marked as answered to keep the discussion visible for curious minds :) .