what's the future of error handling?

Interfaces should be respectful of the work that the user has done up to the point an error occurs. The computer should freeze/salvage as much of the state as makes sense for the context, and provide the ability to resume from there. Kinda like Common Lisp’s condition system, but potentially spanning multiple network nodes, and also surfaced meaningfully in the user land.  It should include contextual suggestions to help “fix” the error, and carry on. Loosely mapping to the Common Lisp restarts. It should speak the user’s language. It shouldn’t gratuitously expose them to the semantic layers beneath. Unless they want to! Which means you need some sort of “moldability” in your error framework.

i agree with the above ^ every error should be result in a question from the user about how to proceed, with the opportunity to fix the issue using any required data from a humane interface for finding it

and what if the error corrupted state or left it in an inconsistent state?

@Mariano Guerra rewind!

so the future is immutable? 🙂

I don't believe in errors or exceptions, because I believe programming is creating models of reality, and you don't get errors or exceptions in reality.

how parsing a csv when given a pdf is a model of reality?

There are two ways of answering that: from the point of view of (a) syntax as type in a programming model, or (b) interfacing between a clean programming model and the dirty realities of legacy tech

Depends on the future of everything else! It makes no sense to design features separately and then bolt them on. Depends on where in the utopian stack you're talking about. Different places will need different, ahem, trade-offs.

↑ and what Kartik sez

Robust Computing

yeah, ideally the error percolates up as a mismatch—for example, somethings undefined. the tool rewinds the execution trace to where that symbol became undefined—gives you the process and lets you edit it such that it doesn’t happen again

.. * tl;dw you mean 😄

I assume @curious_reader is referring to https://www.youtube.com/playlist?list=PLm5k2NUmpIP-4ekppm6JoAqZ1BLXZOztE Very nice internally consistent answer. Fixing error handling this way affects the entire programming model.

I do think @Duncan Cragg is on to something. "Errors" are fundamentally just another control flow path that don't necessarily deserve special treatment. From this I conclude that any shenanigans we want to do with exceptions should also be available for happy-path code as well. I'm pretty sure this means pervasive use of delimited continuations, possibly in the form of algebraic effects.

Or anonymous sum types that are structurally rather than nominally matched. Go's pattern but with a single result.

@Kartik Agaram can you elaborate a bit on what you mean by "structurally matched"? A doc link to a language that does it would be fine. I'm assuming "nominally matched" is the usual ML-style pattern match...

Right. The closest language is https://ceylon-lang.org/documentation/1.3/introduction. Search for 'union type'. Basically structural typing addresses Rich hickey's criticism of Haskell. You don't always want int to match some union type containing ints. But it's good to give programmers the choice. Particularly for errors, it's good to be able to just return an int and have it automatically convert to

int|err

. This approach to error checking feels more parsimonious than first class delimited continuations and algebraic effects.