P4
A DESCRIPTION OF THE PROBLEM :
The checked vs runtime exceptions distinction is problematic in systems that endeavor to engineer away opportunities for the user to make a mistake that results in a checked exception.
As an example, I'm currently working on an application that has about 90,000 lines of Java code. It currently contains about 400 catch blocks. Almost all of the catch blocks fall into one of the following categories:
1. Address a checked exception that can never actually happen (example: NegativeArraySizeException in a case in which the array size is checked to ensure that it's non-negative).
2. Address a checked exception that can only happen in the event of a serious programming error (example: some sort of mismatch between class definitions and their fields due to a call that somehow passes a field from one class and an instance of another class).
3. Address a checked exception that can only happen in the event of a serious system error (example: IOExceptions that can only occur if the file system develops a problem).
The result of all this is a lot of code noise spent addressing checked exceptions that are, in terms of actual cause, more like runtime exceptions or programmer errors.
To address this, I'm proposing a new method declaration keyword, "unchecks." If any line of code in the method throws a checked exception included on the list after the "unchecks" keyword will be automatically converted to a runtime exception without need of a try-catch block. Example:
private void foo() unchecks IOException {
// ...
Files.copy(path1, path2); // No need for try-catch because of unchecks declaration
// ...
}
This would really reduce the noise and would put the information about which checked exceptions are being "laundered" to runtime at the top of the method, rather than burying them in try-catch blocks further down.
The checked vs runtime exceptions distinction is problematic in systems that endeavor to engineer away opportunities for the user to make a mistake that results in a checked exception.
As an example, I'm currently working on an application that has about 90,000 lines of Java code. It currently contains about 400 catch blocks. Almost all of the catch blocks fall into one of the following categories:
1. Address a checked exception that can never actually happen (example: NegativeArraySizeException in a case in which the array size is checked to ensure that it's non-negative).
2. Address a checked exception that can only happen in the event of a serious programming error (example: some sort of mismatch between class definitions and their fields due to a call that somehow passes a field from one class and an instance of another class).
3. Address a checked exception that can only happen in the event of a serious system error (example: IOExceptions that can only occur if the file system develops a problem).
The result of all this is a lot of code noise spent addressing checked exceptions that are, in terms of actual cause, more like runtime exceptions or programmer errors.
To address this, I'm proposing a new method declaration keyword, "unchecks." If any line of code in the method throws a checked exception included on the list after the "unchecks" keyword will be automatically converted to a runtime exception without need of a try-catch block. Example:
private void foo() unchecks IOException {
// ...
Files.copy(path1, path2); // No need for try-catch because of unchecks declaration
// ...
}
This would really reduce the noise and would put the information about which checked exceptions are being "laundered" to runtime at the top of the method, rather than burying them in try-catch blocks further down.