Checked exceptions [Re: Hijacking]

[Bruno Medeiros]

eao197 wrote:
> On Wed, 08 Aug 2007 15:38:14 +0400, Bruno Medeiros 
> <brunodomedeiros+spam at com.gmail> wrote:
> 
>> 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.
> 
> I don't agree (almost complitely). Checked expession is not simply 
> annoying. Sometimes they lead to bad-style and erroneous code. For 
> example imagine you redefine some method:
> 
> class MySpecializedClass extends SomeGeneralClass
> {
>   public void someMethod() throws DomainSpecificException { ... }
> }
> 
> but you need to use temporary file in someMethod() implementation (or 
> need to run some external tool, or need to use some crypto library). And 
> File.createTempFile throws IllegalArgumentException or IOException or 
> SecurityException, but no one of them is in someMethod 'throws' clause.
> 
> In such case you have only two possibilities: wrap the exception which 
> is thrown by File.createTempFile into some another exception (it is good 
> if DomainSpecificException allows that, but in an usual case it don't) 
> or catch and hide the original exception. As I seen in the past many 
> developers prefered catch and hide exception. And this is not a good 
> approach I think.
> 
> So in my opinion it is better to write code which doesn't depend on 
> particular kind of exception. Assumption that any part of code could 
> throws any kind of exception lead to more reliable software (Erlang is 
> an evidence).
> 

I don't see how that is disagreeing with what I said before. Note that 
the above doesn't hide the exception (as in, make it disappear), it gets 
re-thrown as an unchecked exception.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D