Checked exceptions [Re: Hijacking]

[eao197]

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).

The exception safety in much more hard in C++ where there is manual memory  
management and there isn't scope()-constructs like in D. So I hope that  
writting exception safe code in D is much more easy, than in C++ or in  
Java with checked exceptions.

However sometimes is good to know that some method doesn't throw exception  
at all (it could be necessary for exception safety, like C++ convection  
that swap() methods and destructors are exception free). So I suppose to  
introduce 'nothrows' modifier as a sign that some routine is exception  
free:

bool is_item_in_array( int[] array, int item ) nothrows { ... }

Compiler could checks nothrows-routines. It is an error if  
nothrows-routine calls any routine without 'nothrows' modifier.

So it could be an crear advice to programmer: if it has some data which  
must be protected from exception and he calls any routine without  
'nothrows' modifier he must do some action to protect his data.

-- 
Regards,
Yauheni Akhotnikau