|
|
|
|
|
|
by chmike
2869 days ago
|
|
|
Seriously, exceptions are very different from returning an error. Confusing error return with checked exception tells it all. A checked exception is just an exception type specification. When you read code with a call to a function returning an error, you see how the error is handled. With exception, unless there is a try/catch close surrounding the call, you don't know where and how an exception is handled. To me, throwing exceptions is like littering the streets. That feels fine for the one who does it, because he assume someone else will take care of the mess. But the problem is taking care of it, who, how when ? With big projects, this strategy is unmanageable. Correctly handled exceptions don't make middle-ware easier to write or more readable. On the contrary. You know that programs are not only http handlers, right ? |
|
|
A checked exception _requires_ an exception type specification. If you don't handle the exception locally, that is. It's this quality I refer to, when I say checked exceptions are similar to error codes: an API designer, without knowing the full context, requires the call site to do something about it, even if 9/10 call sites could not care less, _especially_ in big projects. Some other commenter linked to this interview [0], which elaborates on that problem.
> With big projects, this strategy is unmanageable.
Clearly, it's possible to have mantainable projects both with and without exception handling.
> You know that programs are not only http handlers, right ?
I find this somewhat condescending, but yes, I do know that. Most programs have system boundaries though, and might recover from quite severe error conditions there.
[0] https://www.artima.com/intv/handcuffs.html