I wonder if there could be an ultra-pessimist errors-first programming language.
The main purpose of any code would be to deal with all possible errors and define them upfront. If, by miracle, your program execution does survive the minefield, you can throw a Success exception.
Errors happen when one or more of a function’s assumed dependencies are missing or invalidated. So in a PL like you’re imagining, every function would need to run an assertion prologue validating all of its static dependencies. As for dynamic dependencies, they would need to be dynamically (continually) validated, probably at multiple scopes (who watches the watchmen?). If you squint your eyes you will see that static dependency checking is in fact partially provided by type systems, the more capable the type system the broader it’s functional coverage. The complexity actually lies in those dynamic dependencies, which are external systems and components, sitting at the other end of some channel, and this includes the very hardware components the function is running on. If you follow this rabbit hole you’ll see that there’s no such things as static dependencies, just allegedly more stable dynamic ones; and that all dependencies are intertwined with each other within the continuum of the universe; and that anything that works is a miracle, built upon hopes and dreams. So we could say that the ultimate exception is a program working as intended, every time. So why even bother programming defensively? Let it crash!
Yes, except for the "defining them upfront" part, which sounds similar in theory to checked exceptions in Java. I'm very partial to this, especially in Go, where nobody ever bothers to propagate errors properly and instead just bubbles up the same `err` object all the way to the top.
Maybe we could define a numeric identifier for each error type we have, which would let us have quite a large number of errors in an already well-known type. I guess we'd have to reserve 0 for the rare success case. In order to make sure people don't forget about it, we can even have our `main` function return an integer!
Actually you have. It is called token ring. Except it is painful to support and we all hate it. Strangely the same philosophy get you Ethernet … ether does not exist. We just do not 100% sure about delivery. And strangely in those days to think this work. And ip as well.
> easily half the code I was writing in Multics was error recovery code.
And it can be worse. IBM, I think it was, back in the 1970s or 80s, said that 80% of the lines of production-ready code dealt with errors - only 20% was doing the actual program functionality.
The main purpose of any code would be to deal with all possible errors and define them upfront. If, by miracle, your program execution does survive the minefield, you can throw a Success exception.