4 ms·
"Exceptions you expect the consumer to handle" should be explicit return values on the function signature instead, via an Either/Result type or similar. Unless
by p1necone 4y ago
"Exceptions you expect the consumer to handle" should be explicit return values on the function signature instead, via an Either/Result type or similar.
Unless you're writing Java where you can force certain exception types to be handled, but people never write that code properly.
- zaphar 4y agoVery few languages actually support Either or Result types ergonomically. I don't have a problem with people using exceptions for these but I do think if the language has compile time type checking it should provide a distinction between checked exceptions and non checked exceptions. I am very much in the minority here but I find it very useful to let robots tell me I forgot something than to discover I forgot it in production. I think this is the useful sort of lazy rather than the not useful sort. Not useful laziness is letting your customers discover the problem.
- p1necone 4y agoYeah I agree. I think the problem with checked exceptions in Java is a combination of misuse on both the consuming and the throwing end. They're amazing when they provide a compile time checked way to make sure consumers handle stuff they actually definitely want to handle, but if you add too much noise then all the consuming code is just going to catch and rethrow even the important ones.
- vbezhenar 4y agoI can't remember a single use case when library could definitely know that consumer must handle that particular exceptions. 100% of checked exception uses must be unchecked.