3 ms·
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 def
by pavlov 2y ago
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.
- condensedtea 2y agoSounds a lot like error handling in Golang :)
- tazu 2y agoYes, and in prod I have a recover() handler that sends me an email with stack trace. Haven't gotten one in a few years...
- kstrauser 2y agoSomewhere a spam filter thinks stack traces look like viagra ads.
- vsnf 2y agoYes, 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.
- fractalb 2y agoPeople then concentrate more on avoiding errors than getting things done.
- AnimalMuppet 2y ago> 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.
- exe34 2y agoAssembly?
- codetrotter 2y agoRust, kind of.
- pilgrim0 2y agoErrors 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!
- omnibrain 2y agoSounds a bit like Eiffel https://en.m.wikipedia.org/wiki/Eiffel_(programming_language) https://en.m.wikipedia.org/wiki/Eiffel_(programming_language...
- ngcc_hk 2y agoActually 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.
- saghm 2y agoMaybe 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!