Comment by spullara

2 days ago

that is the same as saying the method throws IOException

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.

      1 reply →

  • 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.

IOException must be #1 on the list of most ignored exceptions. Like okay what am I supposed to do really I'm just trying to run a select against my db

  • Well, for example, if you had opened a file to put the data into, you might delete the file or restore from a backup. But even if the answer is nothing, bubbling it all the way up to main is not the wrong answer. The point isn't whether you can do something, it's whether someone can do something.