5 ms·

Bruce Eclkel's pretty much state the anti-checked-exception camp: http://www.mindview.net/Etc/Discussions/CheckedExceptions http://www.mindview.net/Etc/Discussi

by russell 17y ago

Bruce Eclkel's pretty much state the anti-checked-exception camp: http://www.mindview.net/Etc/Discussions/CheckedExceptions http://www.mindview.net/Etc/Discussions/CheckedExceptions There are very good comments from both points of view. The blog was written several years ago, so his solution is somewhat dated. I think checked exceptions are a bad idea for a couple of reasons. First is their most acclaimed benefit: they force you to deal with the exception immediately, even if you have no solution for it. You have to decide whether to catch the exception or add a throws clause, which changes the method signature and breaks it for any users of your method. The the default decision for many programmers is to log the exception and swallow it, intending to come back later. I have had to dig through applications to find sql exceptions that were caught but not dealt with. The second big problem I find is the poor design of exception classes. It is not uncommon to find a class that throws a half-dozen exceptions. Every time you call a new method you have a new exception to deal with. Either it should have a single exception with different error codes for the different cases, or the exceptions should be subclassed from a master exception.

lucifer 17y ago
"I think checked exceptions are a bad idea for a couple of reasons. First is their most acclaimed benefit: they force you to deal with the exception immediately, even if you have no solution for it." The use of the word "immediately" informs your misunderstanding of the purpose of a checked exception. Checked exceptions are enforced at compile time (thus "checked" exception). There is no such thing as 'temporal immediacy' at compile time (unlike runtime exceptions). There is potential for spatial immediacy (if we consider the static call stack), but that is not what the compiler cares about. (In other words, you can catch exception Foo at the call site and delegate handling up the call stack by throwing a Bar (cause: Foo)). A compiler enforced handling of an exception declaration insures that the program handles the exception at some level in the call stack, as apparent to the compiler. This whole (endless) discussion regarding checked/unchecked very much mirrors the static-typing/dynamic-typing discussion. You can either consider the merits pragmatically, or, you can adopt a dogmatic (religious) point of view that embraces one paradigm and dismisses the other.
- barrkel 17y ago
  Programming languages shape the way programmers solve problems. To use your terms, when a compiler forces one to deal with a problem with spatial immediacy (i.e. checked exceptions), and the language uses spatial colocation to represent temporal colocation to a greater or lesser degree (as most imperative languages do), then the programmer is being encouraged, quite strongly, to solve the problem in similar space and by consequence in similar time.
  - lucifer 17y ago
    You make a very persuasive point, but I have reservation regarding the words "encourage" and "solve". I would think the fact of the possibility of mapping exceptions (according to some abstraction order mirroring the layering of the overall system) calls for "acknowledge" instead of "solve". And compilers can help with robustness of programs, but their influence on the robustness of programmers is not immediately evident. So perhaps "suggests" instead of "encourage" for a subset of programmers?
    - barrkel 17y ago
      The failure modes of software written in C versus memory safe languages, with particular attention to security and buffer overflows, persuades me very strongly that languages (and their implementations, i.e. compilers) do indeed influence the robustness of programmers. What is a programmer other than the programs he writes?
- russell 17y ago
  By "immediately", I meant as you write the code. Type the code, hit return, and you have an error. "Immediately" you have to decide add a try or change the method signature. I think this causes premature exception handling, just because the programmer wants to get moving along with the code. Checked/unchecked seems to mirror static/dynamic typing, but it doesnt. It's orthogonal. Exception handling is an application specific implementation strategy, but checked exceptions force a "religion" on you.
- scotty79 17y ago

by russell 17y ago

lucifer 17y ago

"I think checked exceptions are a bad idea for a couple of reasons. First is their most acclaimed benefit: they force you to deal with the exception immediately, even if you have no solution for it." The use of the word "immediately" informs your misunderstanding of the purpose of a checked exception. Checked exceptions are enforced at compile time (thus "checked" exception). There is no such thing as 'temporal immediacy' at compile time (unlike runtime exceptions). There is potential for spatial immediacy (if we consider the static call stack), but that is not what the compiler cares about. (In other words, you can catch exception Foo at the call site and delegate handling up the call stack by throwing a Bar (cause: Foo)). A compiler enforced handling of an exception declaration insures that the program handles the exception at some level in the call stack, as apparent to the compiler. This whole (endless) discussion regarding checked/unchecked very much mirrors the static-typing/dynamic-typing discussion. You can either consider the merits pragmatically, or, you can adopt a dogmatic (religious) point of view that embraces one paradigm and dismisses the other.

barrkel 17y ago
Programming languages shape the way programmers solve problems. To use your terms, when a compiler forces one to deal with a problem with spatial immediacy (i.e. checked exceptions), and the language uses spatial colocation to represent temporal colocation to a greater or lesser degree (as most imperative languages do), then the programmer is being encouraged, quite strongly, to solve the problem in similar space and by consequence in similar time.
- lucifer 17y ago
  You make a very persuasive point, but I have reservation regarding the words "encourage" and "solve". I would think the fact of the possibility of mapping exceptions (according to some abstraction order mirroring the layering of the overall system) calls for "acknowledge" instead of "solve". And compilers can help with robustness of programs, but their influence on the robustness of programmers is not immediately evident. So perhaps "suggests" instead of "encourage" for a subset of programmers?
  - barrkel 17y ago
    The failure modes of software written in C versus memory safe languages, with particular attention to security and buffer overflows, persuades me very strongly that languages (and their implementations, i.e. compilers) do indeed influence the robustness of programmers. What is a programmer other than the programs he writes?
russell 17y ago
By "immediately", I meant as you write the code. Type the code, hit return, and you have an error. "Immediately" you have to decide add a try or change the method signature. I think this causes premature exception handling, just because the programmer wants to get moving along with the code. Checked/unchecked seems to mirror static/dynamic typing, but it doesnt. It's orthogonal. Exception handling is an application specific implementation strategy, but checked exceptions force a "religion" on you.
scotty79 17y ago