Re:Rating 26 years of Java changes
by rectang on Sunday October 12, 2025 @12:06PM
(#45559225)
The point of avoiding invisible control flow is not to identify the type of the error, but to identify all locations in the code where recoverable errors may occur.
> One persons panic may just be another error case for someone else.
We can make a strong distinction between recoverable errors (e.g. this I/O operation may fail) versus unrecoverable errors that may leave the process in an unsound state, such as divide-by-zero or out-of-bounds array access[1].
There are some problem domains where even unrecoverable errors are not allowable, and programmers in those domains have to grapple with the panic mechanism.
But for the rest of us, it is useful to be able to distinguish between recoverable and unrecoverable errors — and to know how we have handled all possible sites which could result in recoverable errors.
> One persons panic may just be another error case for someone else.
We can make a strong distinction between recoverable errors (e.g. this I/O operation may fail) versus unrecoverable errors that may leave the process in an unsound state, such as divide-by-zero or out-of-bounds array access[1].
There are some problem domains where even unrecoverable errors are not allowable, and programmers in those domains have to grapple with the panic mechanism.
But for the rest of us, it is useful to be able to distinguish between recoverable and unrecoverable errors — and to know how we have handled all possible sites which could result in recoverable errors.
[1] Joe Duffy explains it well: https://joeduffyblog.com/2016/02/07/the-error-model/#bugs-ar...