Checked exceptions [Re: Hijacking]
Bruno Medeiros
brunodomedeiros+spam at com.gmail
Wed Aug 8 04:38:14 PDT 2007
Bill Baxter wrote:
> Nick Sabalausky wrote:
>> "Rioshin an'Harthen" <rharth75 at hotmail.com> wrote in message
>> news:f974u9$9k1$1 at digitalmars.com...
>>> "Walter Bright" <newshound1 at digitalmars.com> kirjoitti viestissä
>>> news:f95leh$hn4$1 at digitalmars.com...
>>>> It might be one of those things like exception specifications where
>>>> everyone says it's a good idea but guiltily hate in secret <g>.
>>> Exception specification *is* a good idea. Although I do hate it - try
>>> to remember what a specific method may throw when you write your
>>> code, especially if the error is ambiguous like "Unhandled exception"
>>> it's really irritating - but I hate unspecified exceptions even more,
>>> as the problem then is to even remember to put in the necessary
>>> try-catch-finally blocks.
>>
>> Not to start a big big debate on it, but my own personal feeling on
>> that (after having used a fair amount of it) is that the specification
>> of exceptions belongs in generated documentation (whether
>> javadoc-style or as part of the IDE as with "some_function() -> Called
>> By..."). I normally prefer having to explicity specify things (yea,
>> strong-typing fan here ;) ), but personally, I find it overkill in
>> this case. (Not to mention it gave me flashbacks of writing C/C++
>> headers. j/k ;) ).
>
> I agree with this 100%. With check exceptions it just becomes too
> annoying and verbose. Without them, often it is too difficult to find
> out what exceptions are possible for a function to throw.
>
> So the right place seems to be an analysis / doc-generation tool / IDE.
>
> --bb
Interesting thing I'd like to mention, again about how IDEs affect the
language design and influence it's advantages and disadvantages.
I too find checked exceptions annoying, but this is an example of a
language disadvantage has been practically nullified by the IDE (JDT).
First I took a slightly modified ExceptionAdapter class such as the one
from Bruce Eckel's article:
http://www.mindview.net/Etc/Discussions/CheckedExceptions
(basicly ExceptionAdapter is class that wraps a checked exception in an
unchecked exception, allowing it to be thrown unchecked)
So when you have something like this:
foo.doSomething(); // throws a normal exception
and Java will complain that an exception is thrown, you add this:
try {
foo.doSomething(); // throws a normal exception
} catch(FooException fe) {
ExceptionAdapter.unchecked(fe);
}
and there is no longer a compiler error (unchecked is a static method
that wraps the exception), without having needed to put throws clauses
in all method along the call hierarchy.
This is an interesting workaround, but it is still annoying to have to
write that try-catch code whenever an exception is thrown.
The second part is where JDT comes in. Whenever you have this:
foo.doSomething(); // throws a normal exception
the IDE compiler will show and highlight the error, and then you can
press Ctrl+1 on the error (Quick-Assist), showing a list of possible
fixes, one of them being "Surround with Try-Catch". If you select it,
JDT will automatically add the try-catch code, like this:
try {
foo.doSomething(); // throws a normal exception
} catch(FooException fe) {
// TODO: catch exception here
}
Note that the catch clause is automatically set to the thrown exception.
But furthermore you can change the template of code that is created with
this try-catch quick-fix, so that instead of the "// TODO:" line, you
put the "ExceptionAdapter.unchecked(...);" line. So now whenever this
quick fix is invoked, it will automatically generate all necessary code,
and you're now able to avoid the checked exception problem with just a
few keystrokes (Ctrl+1, Down, Enter). :)
As an added bonus, if some time you feel the need to rigorously specify
your code, you can then search for calls of the
ExceptionAdapter.unchecked method, to find points where you can turn
unchecked exceptions into checked ones.
--
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
More information about the Digitalmars-d
mailing list