3 ms·
> what happens if one of your inner-inner-inner functions returns null when the docs say it shouldn't? My choice of language wouldn't have the concept of "null
by kaoD 8y ago
> what happens if one of your inner-inner-inner functions returns null when the docs say it shouldn't?
My choice of language wouldn't have the concept of "null".
If it somehow returns an Option type... well, the docs would say it, and it won't typecheck unless I handle it.
> If you want strongly typed errors then you could use a language with checked exceptions (Java).
Yes, typed error handling looks an awful lot like Java's checked exceptions.
Buuuuut exceptions magically unwind the stack at unknown points. I don't like my stacks unwinded unless I explicitly tell them to. Function exit points should be explicit.
Also: it has unchecked exceptions too, runtime exceptions (null pointers, anyone?) and lacks the expressiveness to handle error propagation while not being a pain in the ass.
- shawnz 8y agoI actually think checked exceptions make handling error propagation much easier than Option types. In a language with checked exceptions, if you want to propagate the error, all you have to do is declare that intent. With Option types, there is a need for boilerplate unwrapping code in almost every place where you want to use the value.
- kaoD 8y ago> With Option types, there is a need for boilerplate unwrapping code in almost every place where you want to use the value. Disagree, in my favorite language you just add "?" to the possibly-erroring function et voilá, error propagated. Even better, since errors are functor-like (map) and monad-like (and_then), I'm mostly never unwrapping myself. This has the advantage that it's explicit, instead of exceptions implicitly returning early (sometimes to great amusement).
- Faark 8y ago> Disagree, in my favorite language you just add "?" to the possibly-erroring function et voilá, error propagated And one of the first things I had to learn in rust was how make this happen with different error types. After that it was pretty much the same as exceptions. What functions return errors is a little more obvious, at the cost of extra boiler plate (most stuff being Result<...> anyway) Checked exceptions Java style could be a perfect balance with just a few modifications. Compiler/IDE should mostly know whats thrown where, so specifying it manually should rarely be necessary. And still could visualize what can fail and with what errors.