Comment by sieve
2 days ago
It might throw one. There is a difference between documenting what exceptions can be thrown and forcing every consumer to handle them.
2 days ago
It might throw one. There is a difference between documenting what exceptions can be thrown and forcing every consumer to handle them.
returning a non-success you either handle it or pass it up the chain, potentially with not a lot of information about what originally caused it. with an exception you can retain the full information about what happened by either rethrowing it, throwing your own exception with it embedded as the cause or declaring that you don't handle it by saying you can throw it.
I generally prefer exceptions to result codes. You can even use the mechanism to throw useful results across nested function calls.
I do prefer Maybe/Option/Either style returns in some cases though. Makes for a cleaner API.
So each method has its uses.
I also have this nuanced view. I am glad my hashmaps don't throw KeyNotFoundException.
Yeah, checked exceptions are weird. Almost everything has some way to fail. The exact type of exception is usually meaningless, more like there are a couple of broad categories analogous to HTTP 4xx vs 5xx, and even then you usually don't want to handle it right there.