Ted Leung on the air
Ted Leung on the air: Open Source, Java, Python, and ...
Ted Leung on the air: Open Source, Java, Python, and ...
Sun, 31 Aug 2003
Checked exceptions vs Unchecked Exceptions + Tests
Bill de Hora is contributing
his thoughts to the checked exception debate. His post has some good points
As I was thinking about this some more, checked exceptions start looking like explicit typing. The reason people want checked exceptions is to make sure that no error conditions go unprocessed. Same thing that explicit typing people want. But let's apply the testing argument. If your testcases actually tested the relevant error conditions, then you wouldn't need to have a language mechanism to ensure that the errors got handled. At least, you could make all exceptions unchecked, and eliminate the multi-arm catch hairballs that are lying around. It's not like all those catch blocks that are empty, printing stacktraces, or logging exceptions are really improving the robustness of the systems that they are in.
[01:10] |
[computers/programming] |
# |
TB |
F |
G |
5 Comments |
Ted Leung contrasts checked exceptions with testing: If your testcases actually tested the relevant error conditions, then you wouldn't need to have a language mechanism to ensure that the errors
Posted by Trackback from Bill de hÓra at Sun Aug 31 09:44:18 2003
Posted by Trackback from Bill de hÓra at Sun Aug 31 09:44:18 2003
I like the power of untyped language. My favorite is Prolog -- atoms and lists.
But I've also needed strongly typed language for probabilistic work. Loss of precision is a bear. I need Java, C, or FORTRAN there.
In talking of exceptions their are applications, components, and system resources.
Loosing a network connection is a resource issue. Transparently, I can try to reconnect. But I can't keep trying forever. Do I throw a runtime exception or a declared exception?
What of file i/o errors due to actual disk sector errors? They are meaningless without context. Their consequence is fundamental and far reaching.
These are resource related exceptions that the unit test suite with 100% coverage doesn't address.
In Prolog the errors cause failure and I'm able to backtrack a cover the next case. But I have to specify that case in clauses.
In the embedded data manager I need to tell the enclosing application of resource related failures - the application's integrity is threatened. The app writer can dumb it down to a runtime exception if they choose.
Like statistics and the precision requirement, resource consumption has an integrity requirement. Checked exceptions make the threat explicit.
Posted by Margaret Green at Sun Aug 31 11:00:19 2003
But I've also needed strongly typed language for probabilistic work. Loss of precision is a bear. I need Java, C, or FORTRAN there.
In talking of exceptions their are applications, components, and system resources.
Loosing a network connection is a resource issue. Transparently, I can try to reconnect. But I can't keep trying forever. Do I throw a runtime exception or a declared exception?
What of file i/o errors due to actual disk sector errors? They are meaningless without context. Their consequence is fundamental and far reaching.
These are resource related exceptions that the unit test suite with 100% coverage doesn't address.
In Prolog the errors cause failure and I'm able to backtrack a cover the next case. But I have to specify that case in clauses.
In the embedded data manager I need to tell the enclosing application of resource related failures - the application's integrity is threatened. The app writer can dumb it down to a runtime exception if they choose.
Like statistics and the precision requirement, resource consumption has an integrity requirement. Checked exceptions make the threat explicit.
Posted by Margaret Green at Sun Aug 31 11:00:19 2003
Via Ted Leung and Bill De HÓra, I read Ross Judson's comments on checked exceptions. This subject just keeps coming back... I blogged about this half a year ago arguing against checked exceptions. In all honesty, I actually do like checked exceptions, but only when used in moderation. The problem is that the typical Java developer uses them to the...
Posted by Trackback from public virtual MemoryStream at Sun Aug 31 15:42:09 2003
Posted by Trackback from public virtual MemoryStream at Sun Aug 31 15:42:09 2003
This is really very backwards thinking. Which one is easier: making a developer write loads of tests to ensure his code is bug-free or forcing the developer to acknowledge and handle error conditions in his code? The idea that tests (if they get written as if there's time to write them) will magically compensate for the deficiencies of the language is just plain wrong.
Posted by Bo at Sun Aug 31 21:52:43 2003
Posted by Bo at Sun Aug 31 21:52:43 2003
The idea is that you have to write tests if you want to have any confidence that the code is good, so you're not saving any effort by forcing the checked exception. Are you saying that all those catch blocks that swallow exceptions, print a stack trace, or log to a file are actually improving the reliability of the code? In the kinds of environments where tests don't get written, the catch blocks are usually junk as well.
Posted by Ted Leung at Mon Sep 1 01:12:34 2003
Posted by Ted Leung at Mon Sep 1 01:12:34 2003
You can subscribe to an RSS feed of the comments for this blog:
Add a comment here:
You can use some HTML tags in the comment text:
To insert a URI, just type it -- no need to write an anchor tag.
Allowable html tags are:
You can also use some Wiki style:
URI => [uri title]
<em> => _emphasized text_
<b> => *bold text*
Ordered list => consecutive lines starting spaces and an asterisk
To insert a URI, just type it -- no need to write an anchor tag.
Allowable html tags are:
<a href>
, <em>
, <i>
, <b>
, <blockquote>
, <br/>
, <p>
, <code>
, <pre>
, <cite>
, <sub>
and <sup>
.You can also use some Wiki style:
URI => [uri title]
<em> => _emphasized text_
<b> => *bold text*
Ordered list => consecutive lines starting spaces and an asterisk