Home arrow static arrow Java Programming [Archive] - compile-time exceptions !!
Warning: Creating default object from empty value in /www/htdocs/w008deb8/wiki/components/com_staticxt/staticxt.php on line 51
Java Programming [Archive] - compile-time exceptions !!
This topic has 202 replies on 14 pages.    1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | Next »

Posts:2,830
Registered: 9/1/03
compile-time exceptions !!  
Jul 27, 2004 3:52 AM



 
Hello,

This issue has been raised here a few times, and i've even argued the opposite of what I am about to suggest now ... but here it goes:

I recently am running in to quite a few of these very annoying exceptions with the
knowledge that I can do absolutely nothing (at least in this stage of development)
but completely ignore these errors. Obviously I have to write stupid bits of code like:
try { op(); } catch(Exception e){ }
alot because there is no alternative.

However, just a few minutes ago i discovered the "-nowarn" switch on "javac". Then
I thought: "Great! Surely it will be a warning not an error that I have forgotten the
exception handling code." Of course (and as the lack of class-file-generation should
have told me) it is not a warning.

The obvious question being ... why not ? It seems like a great candidate for a warning,
imo ... (although so does "unreachable statement" but anyway....) so I was just wondering
if anyone has any interesting reasons for this being the case ..
 

Posts:3,183
Registered: 10.09.03
Re: compile-time exceptions !!  
Jul 27, 2004 4:18 AM (reply 1 of 202)



 
Because that's the way exception handling works. When something borks, you MUST catch it somewhere or else the error will never be noticed. The exception is the RuntimeException and all derived exceptions, you don't have to catch those.

Remember: java is very strict and thank god for that. This leads to far less runtime mistakes, which is always a plus in my book.
 

Posts:2,830
Registered: 9/1/03
Re: compile-time exceptions !!  
Jul 27, 2004 4:33 AM (reply 2 of 202)



 
Because that's the way exception handling works. When
something borks, you MUST catch it somewhere or else
the error will never be noticed.

But so what ? We notice it via the warning.

We can then decide if we would really like to put handling
code around it, or if we don't. If we don't the functionallity
would be no different from a RuntimeException.

Remember: java is very strict and thank god for that.
This leads to far less runtime mistakes, which is
always a plus in my book.

Well of course; obviously I am not suggesting to make more mistakes,
it just makes for a very annoying situation when compile-time exceptions
are placed (perhaps inappropriately) and then we are forced to handle
them even though there is this apparent "warning" class of notifications
the compiler could be giving us instead.
 

Posts:3,055
Registered: 18/06/98
Re: compile-time exceptions !!  
Jul 27, 2004 6:00 AM (reply 3 of 202)



 
The two schools of exception handling: Java vs. C#

In Java you NEED to handle the exception if it is declared in the "throws" clause.

In C# you handle it if you want to do it. If you don't handle it, you will get an unhandled run-time exception instead of the archetypical Java code "try {somethingTrulyDangerous();} catch (Throwable t) {/* swallow all errors */} " that could "quench" an important error condition.

Both ways have problems and virtues.
 

Posts:2,830
Registered: 9/1/03
Re: compile-time exceptions !!  
Jul 27, 2004 6:07 AM (reply 4 of 202)



 
The two schools of exception handling: Java vs. C#

Yes, I know, I actually program in c# mainly now-a-days.

In Java you NEED to handle the exception if it is
declared in the "throws" clause.

Lets be clear ... I don't want to forget about the compile-time exceptions
altogether, I just want them to be warnings not errors. I am
just looking for the reason that they were chosen to be errors.

Is it because as developers when we write a CT exception we are
really really concerned about this method and want the programmer
to be aware of the exception and handle it ? Yes ? The warning system
still provides this behaviour; we, the caller, still know about the exception
in a fashion that we wouldn't if the exception was simply a RT one.

However with the warning system we are also allowed the freedom to
ignore the exception for now, instead of having to forcefully ignore the
thing (try { op(); } catch(Exception e){}).

It just seems appropriate that the CT exception makes use of the warning
system not the error system in the compiler.
 

Posts:21,718
Registered: 98-02-20
Re: compile-time exceptions !!  
Jul 27, 2004 6:29 AM (reply 5 of 202)



 
In C# you handle it if you want to do it. If you don't
handle it, you will get an unhandled run-time
exception instead of the archetypical Java code "try
{somethingTrulyDangerous();} catch (Throwable t) {/*
swallow all errors */} " that could "quench" an
important error condition.

The C# model seems to follow the C++ view more than Java's. C++ doesn't force you to handle exceptions, and it has that centerfielder "catch (...)" notation that handles everything.

Both ways have problems and virtues.

Having used both I prefer the Java approach. When I went back to C++ I missed Java exceptions.

%
 

Posts:6,750
Registered: 1/25/04
Re: compile-time exceptions !!  
Jul 27, 2004 8:26 AM (reply 6 of 202)



 
Is it because as developers when we write a CT
exception we are
really really concerned about this method and want the
programmer
to be aware of the exception and handle it ? Yes ?

I think so - as a developer I have the freedom to designate an exception as something that must or need not be handled somewhere else in the code.

The
warning system
still provides this behaviour; we, the caller, still
know about the exception
in a fashion that we wouldn't if the exception was
simply a RT one.

Do you know how many developers totally ignore all warnings? As I wild guess I would say most of them.

However with the warning system we are also allowed
the freedom to
ignore the exception for now, instead of having to
forcefully ignore the
thing (try { op(); } catch(Exception e){}).

That's fine, but the problem is you would also have the freedom to ignore it forever. That's something that by definition a checked exception should not allow. I think it's better the way it is, because otherwise lazy developers (ie a lot of people) would just ignore the warnings and there would effectively be no such thing as checked exceptions. Do that for a few months and then it's too late to go back - it would take too long to go back and catch all the checked exceptions you've been ignoring. This way the compiler keeps us honest. Which is after all what it's there for (partly).
 

Posts:37,103
Registered: 3/30/99
Re: compile-time exceptions !!  
Jul 27, 2004 9:11 AM (reply 7 of 202)



 

However with the warning system we are also allowed
the freedom to
ignore the exception for now, instead of having to
forcefully ignore the
thing (try { op(); } catch(Exception e){}).

It just seems appropriate that the CT exception makes
use of the warning
system not the error system in the compiler.

I'm quite happy that Java won't allow me to compile without unhandled checked exceptions. To do otherwise seems to defeat the best aspect of the exception handling mechanism--the gurantee that I know what can go wrong when I call a method. I don't want to use a library where the methods don't declare any exceptions but are throwing checked exceptions all over the place. What would be the advantage to allowing compilation with unhandled checked exceptions, other than less typing for the programmer?
 

Posts:10
Registered: 6/26/03
Re: compile-time exceptions !!  
Jul 27, 2004 9:41 AM (reply 8 of 202)



 
Two quote Barney Fife:
There are two kinds of Exceptions in Java...the quick and the dead.
Okay well not quite.
checked and unchecked.....and only checked exceptions need appear in the throws clauses.
checked exceptions that may be thrown in a method MUST either be caught or declared in the method's throw clause...They are called CHECKED exceptions because both the Java compiler and JVM check to make sure these methods are following the rules!!

In general try to handle these exceptions at the root (deepest level), if the information needed to handle the exception is not available then the exception should be thrown.
Unchecked Exceptions..aka RunTimeExceptions(subclasses of Error and RunTimeException) are most catastrophic and usually can't be handled by the developer...NoClassDefFoundError..OutOfMemory...

the JLS recommends not throwing RuntimeExceptions but it can be done....
The great minds of JAVA made sure we have a structured way to handle these conditions. These conditions due force lazy coders to handle error conditions....but Java doesn't force you to design your programs to take advantage of these features.

 

Posts:37,103
Registered: 3/30/99
Re: compile-time exceptions !!  
Jul 27, 2004 9:59 AM (reply 9 of 202)



 
Okay well not quite.
checked and unchecked.....and only checked exceptions
need appear in the throws clauses.

Thanks, but we're aware of that. The question was "Why can't we tell the compiler to compile even with unhandled checked exceptions, effectively turning them into unchecked exceptions? That is, why are the rules so strict?"

I believe the reason they are is so that client code can put bounds on what can go wrong when calling a method. If that strictness goes away, the client has no way of knowing what might go wrong. (Even if that's not the reason the rules were set up as they are, I consider it a good reason to keep them that way.)

In general try to handle these exceptions at the root
(deepest level), if the information needed to handle
the exception is not available then the exception
should be thrown.

I try to follow "throw early, catch late." That is, as soon as you know something's wrong, throw an exception. Most exception handling should occur higher up the call chain. Lower layers may wrap in a more appropriate exception for that layer and rethrow, but in general, I can't assume I know what my caller wants to do if there was a problem, so I bail out and pass all the information on to him.
 

Posts:2,830
Registered: 9/1/03
Re: compile-time exceptions !!  
Jul 27, 2004 3:17 PM (reply 10 of 202)



 
Is it because as developers when we write a CT
exception we are
really really concerned about this method and want
the
programmer
to be aware of the exception and handle it ? Yes ?

I think so - as a developer I have the freedom to
designate an exception as something that must or need
not be handled somewhere else in the code.

The
warning system
still provides this behaviour; we, the caller, still
know about the exception
in a fashion that we wouldn't if the exception was
simply a RT one.

Do you know how many developers totally ignore all
warnings? As I wild guess I would say most of them.

Deprecated method is a warning also though isn't it ? And that
isn't ignored.

However with the warning system we are also allowed
the freedom to
ignore the exception for now, instead of having to
forcefully ignore the
thing (try { op(); } catch(Exception e){}).

That's fine, but the problem is you would also have
the freedom to ignore it forever. That's something
that by definition a checked exception should not
allow. I think it's better the way it is, because
otherwise lazy developers (ie a lot of people) would
just ignore the warnings and there would effectively
be no such thing as checked exceptions. Do that for a
few months and then it's too late to go back - it
would take too long to go back and catch all the
checked exceptions you've been ignoring. This way the
compiler keeps us honest. Which is after all what
it's there for (partly).

Yes, and I believe the warning system still allows us to do this. I generally
don't ignore warnings at all actually. The warning system was provided in
the compiler for just this reason: "Hey, don't forget about this method, it has
an exception you should really know about!".

Not: "Hey, you are so dumb I am going to force you to put a (maybe usless)
try/catch around this operation.".
 

Posts:2,830
Registered: 9/1/03
Re: compile-time exceptions !!  
Jul 27, 2004 3:20 PM (reply 11 of 202)



 

However with the warning system we are also allowed
the freedom to
ignore the exception for now, instead of having to
forcefully ignore the
thing (try { op(); } catch(Exception e){}).

It just seems appropriate that the CT exception
makes
use of the warning
system not the error system in the compiler.

I'm quite happy that Java won't allow me to compile
without unhandled checked exceptions. To do otherwise
seems to defeat the best aspect of the exception
handling mechanism--the gurantee that I know what can
go wrong when I call a method. I don't want to use a
library where the methods don't declare any exceptions
but are throwing checked exceptions all over the
place. What would be the advantage to allowing
compilation with unhandled checked exceptions, other
than less typing for the programmer?

Don't underestimate the benefits of less typing, it's the reason we don't
program in c/c++/assembly.

But more seriously, yes, less typing. Really the only alternative to writing
complete exception-handling style code is just to try / catch / ignore the
exception which is substantially worse then having the exceptions always
appear in the warning window until we handle it.

If we have applied our checked-exception avoidance system onto some
methods it is quite likely we will forget about them until some review of the
code.
 

Posts:2,830
Registered: 9/1/03
Re: compile-time exceptions !!  
Jul 27, 2004 3:22 PM (reply 12 of 202)



 
If that strictness goes away, the client has
no way of knowing what might go wrong. (Even if that's
not the reason the rules were set up as they are, I
consider it a good reason to keep them that way.)

And moving them to be "warnings" instead of "errors" would not change this fact.
 

Posts:37,103
Registered: 3/30/99
Re: compile-time exceptions !!  
Jul 27, 2004 5:37 PM (reply 13 of 202)



 
If that strictness goes away, the client has
no way of knowing what might go wrong. (Even if
that's
not the reason the rules were set up as they are, I
consider it a good reason to keep them that way.)

And moving them to be "warnings" instead of "errors"
would not change this fact.

Yes, it would. If you build your library with "only warn about unhandled checked exceptions, but still compile," then you might have built a library with a method that throws IOException, but doesn't declare it in its throws clause. When I use your library, and I call your method, since you didn't declare it in the throws clause, I have no way of knowing that you throw it, so I won't try to catch it. I don't know what can go wrong when calling your method.

Regardless of how I set my compiler switches, because the guy who built the library I'm using compiled with the evil switch, all exceptions in that library are suddenly unchecked.

Why not just add switches to selectively turn off any language rules you find inconvenient?
 

Posts:37,103
Registered: 3/30/99
Re: compile-time exceptions !!  
Jul 27, 2004 5:40 PM (reply 14 of 202)



 
But more seriously, yes, less typing. Really the only
alternative to writing
complete exception-handling style code is just to try
/ catch / ignore the
exception which is substantially worse

So don't do it. Implement complete exception handling. To not do so just seems lazy. It's also sometimes easier to just put a whole bunch of **** into one method or class, rather than taking the time to do decent OO design, and the compiler even allows it, but that doesn't mean it's a good idea.

If we have applied our checked-exception avoidance
system onto some
methods it is quite likely we will forget about them
until some review of the
code.

Then don't do that in the first place.

Do people really do this? Catch Exception as a quickie when coding, with the intent to come back and fix it later?

shudder
 
This topic has 202 replies on 14 pages.    1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | Next »