4 ms·

Some checked exceptions make a lot of sense to try to catch and fix. FileNotFoundException is something my code can probably recover from - you asked for a fil

by Imnimo 6y ago

Some checked exceptions make a lot of sense to try to catch and fix. FileNotFoundException is something my code can probably recover from - you asked for a file, it's not there, let me ask for a different file. Having a file reading method declare that it throws FileNotFoundException can be a helpful reminder to make sure you handle that possibility. But then there are other types of checked exceptions that are almost certainly unrecoverable because they happen way down in some other third party code. And then you get the endless chain of "throws" all the way back up the code base.

karatinversion 6y ago
I think there's a point to be made here about how checked exceptions interact with java's type system. FileNotFoundException is a pretty great checked exception - it's concrete enough that the caller actually has a chance of doing something useful in response. But most of the java standard library is designed with rather abstract APIs. Take java.io.Reader - it represents an arbitrary input source, so the Reader.read() method is declared to throw the very generic IOException. The subclasses don't make these any more concrete, leading to absurdities like StringReader.read() having a checked IOException.
ragnese 6y ago
> But then there are other types of checked exceptions that are almost certainly unrecoverable because they happen way down in some other third party code. And then you get the endless chain of "throws" all the way back up the code base. No you don't. When your code calls ThirdPartyAPI and it throws one of these checked exceptions that you know you can't recover from, you wrap it in a RuntimeException and rethrow. Then it's totally invisible to the rest of your code. Likewise, you should never have a method that throws 10 kidns of checked exceptions. You should be writing your own custom exceptions that wrap downstream exceptions into forms that are useful for you and your code (or people who will use your code). The biggest issue with checked exceptions is that people refuse to think through their unhappy paths.
- gmueckl 6y ago
  Wrapping exceptions when re-throwing can be really useful. I think that this feature is often underused, especially by people who complain about checked exceptions.
  - ragnese 6y ago
    I suspect that most Java devs have literally never considered anything beyond "Handle it here or rethrow it as-is".
  - singron 6y ago
    E.g. Future wraps any Throwable in ExecutionException, which is a checked exception. But ExecutionExeption could wrap any exception! It may as well just throw Exception. I really would have loved e.g. Future<Value,IOException|FooException>. Obviously it gets erased in the executor, but if your code holds on to it, it could maintain checked exceptions over the async boundary.
hota_mazi 6y ago
> FileNotFoundException is something my code can probably recover from - you asked for a file Actually, no. Sometimes it is fatal, and sometimes it's not. If the file being open is expected to be part of the distribution and your app can't start without it, it's fatal. If it's a file picked by the user, it's most likely recoverable. The main problem is that every single one of these exceptions should be able to be either runtime or checked, and that choice should be made by the application. Open question: should this decision be made at the call site or the use site?
- jimbobimbo 6y ago
  Call site vs use site is a great dichotomy for this discussion. My position is that the caller decides how to deal with exceptions. When I'm adding a new operation to my web app, I won't add any exception handling at all. Why would I? There's a central exception handler in my app, which will log exception, analyze its type and return an appropriate status code to the caller (e.g. 500 or 400). If there's a kind of failure my centralized handler doesn't handle correctly, I'll add an explicit handler in the new operation, which would do the right thing in some cases, while the rest of issues are handled centrally still. Checked exceptions make me have dummy handlers all over the place.
theandrewbailey 6y ago
Whenever I need to convert a string to a UTF-8 byte array, or do a SHA-256 hash, I need to catch UnsupportedEncodingException or NoSuchAlgorithmException respectively. These are ubiquitous standards built into every JVM. It's impossible to recover from these exceptions, but it's impossible to not have these standards. It's one of examples of astronaut architecture[1] that I've needed to get around. I have a throwable type JVMNotSupportedError[0] specifically to wrap these possible but will never be thrown exceptions. Its sole reason for existence, theoretically, is to yell at the user to get a better JVM. [0] https://github.com/theandrewbailey/toilet/blob/master/libWebsiteTools/src/libWebsiteTools/JVMNotSupportedError.java https://github.com/theandrewbailey/toilet/blob/master/libWeb... [1] https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/ https://www.joelonsoftware.com/2001/04/21/dont-let-architect...

by Imnimo 6y ago

karatinversion 6y ago

I think there's a point to be made here about how checked exceptions interact with java's type system. FileNotFoundException is a pretty great checked exception - it's concrete enough that the caller actually has a chance of doing something useful in response. But most of the java standard library is designed with rather abstract APIs. Take java.io.Reader - it represents an arbitrary input source, so the Reader.read() method is declared to throw the very generic IOException. The subclasses don't make these any more concrete, leading to absurdities like StringReader.read() having a checked IOException.

ragnese 6y ago

> But then there are other types of checked exceptions that are almost certainly unrecoverable because they happen way down in some other third party code. And then you get the endless chain of "throws" all the way back up the code base. No you don't. When your code calls ThirdPartyAPI and it throws one of these checked exceptions that you know you can't recover from, you wrap it in a RuntimeException and rethrow. Then it's totally invisible to the rest of your code. Likewise, you should never have a method that throws 10 kidns of checked exceptions. You should be writing your own custom exceptions that wrap downstream exceptions into forms that are useful for you and your code (or people who will use your code). The biggest issue with checked exceptions is that people refuse to think through their unhappy paths.

gmueckl 6y ago
Wrapping exceptions when re-throwing can be really useful. I think that this feature is often underused, especially by people who complain about checked exceptions.
- ragnese 6y ago
  I suspect that most Java devs have literally never considered anything beyond "Handle it here or rethrow it as-is".
- singron 6y ago
  E.g. Future wraps any Throwable in ExecutionException, which is a checked exception. But ExecutionExeption could wrap any exception! It may as well just throw Exception. I really would have loved e.g. Future<Value,IOException|FooException>. Obviously it gets erased in the executor, but if your code holds on to it, it could maintain checked exceptions over the async boundary.

hota_mazi 6y ago

> FileNotFoundException is something my code can probably recover from - you asked for a file Actually, no. Sometimes it is fatal, and sometimes it's not. If the file being open is expected to be part of the distribution and your app can't start without it, it's fatal. If it's a file picked by the user, it's most likely recoverable. The main problem is that every single one of these exceptions should be able to be either runtime or checked, and that choice should be made by the application. Open question: should this decision be made at the call site or the use site?

jimbobimbo 6y ago
Call site vs use site is a great dichotomy for this discussion. My position is that the caller decides how to deal with exceptions. When I'm adding a new operation to my web app, I won't add any exception handling at all. Why would I? There's a central exception handler in my app, which will log exception, analyze its type and return an appropriate status code to the caller (e.g. 500 or 400). If there's a kind of failure my centralized handler doesn't handle correctly, I'll add an explicit handler in the new operation, which would do the right thing in some cases, while the rest of issues are handled centrally still. Checked exceptions make me have dummy handlers all over the place.

theandrewbailey 6y ago

Whenever I need to convert a string to a UTF-8 byte array, or do a SHA-256 hash, I need to catch UnsupportedEncodingException or NoSuchAlgorithmException respectively. These are ubiquitous standards built into every JVM. It's impossible to recover from these exceptions, but it's impossible to not have these standards. It's one of examples of astronaut architecture[1] that I've needed to get around. I have a throwable type JVMNotSupportedError[0] specifically to wrap these possible but will never be thrown exceptions. Its sole reason for existence, theoretically, is to yell at the user to get a better JVM. [0] https://github.com/theandrewbailey/toilet/blob/master/libWebsiteTools/src/libWebsiteTools/JVMNotSupportedError.java https://github.com/theandrewbailey/toilet/blob/master/libWeb... [1] https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/ https://www.joelonsoftware.com/2001/04/21/dont-let-architect...