3 ms·
This is the same distinction and motivation that led to Java's checked exceptions vs RuntimeException. It seemed like a good idea to enforce at the language lev
by bonoboTP 8mo ago
This is the same distinction and motivation that led to Java's checked exceptions vs RuntimeException. It seemed like a good idea to enforce at the language level to handle what the author calls "known" errors, but treat "unknown" ones more leniently.
It led to a lot of boilerplate and as far as I know with hindsight it's seen as a bad design choice because the line is not so clear to draw.
As a first-order approximation it's good to learn about though, if you haven't heard about the concept. But I'd say this idea is introduced usually in the first programming course in an undergraduate college program.
- jaen 8mo agoThe problem was mostly Java, not the idea. Java enforced a rigid (static) disjoint exception hierarchy (necessitating the boilerplate wrapping), no error inference, inability to parametrize over thrown exceptions etc. etc. Basically fired all the language design footguns due to lack of experience and foresight (understandable at that point in history). I'm sure this can be done with an actually decent design, and Rust developers do seem to be innovating in this space with the various error handling crates.