perfsonar development work

[Uros Juvan <>]

I think changing those exceptions to unchecked is very bad idea.
Unchecked exception (RuntimeException or Error classes) are used primarily by
JVM to report runtime fatal errors like NullPointerException.

If I cite 'The Java Language Specification' located at:

http://java.sun.com/docs/books/jls/second_edition/html/exceptions.doc.html

"11.2.1 Why Errors are Not Checked
Those unchecked exception classes which are the error classes (Error and its
subclasses) are exempted from compile-time checking because they can occur at
many points in the program and recovery from them is difficult or impossible. 
A
program declaring such exceptions would be cluttered, pointlessly."

If you read the followin excerpt from Java Tutorial:

http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html

"Generally speaking, do not throw a RuntimeException or create a subclass of
RuntimeException simply because you don't want to be bothered with specifying
the exceptions your methods can throw.

Here's the bottom line guideline: If a client can reasonably be expected to
recover from an exception, make it a checked exception. If a client cannot do
anything to recover from the exception, make it an unchecked exception. "


it should be clear, that usage of RuntimeException is strongly discouraged
just because you do not want to declare throws statements.

On Fri, May 18, 2007 at 09:30:15AM +0200, Roman Lapacz wrote:
> Michael Bischoff wrote:
> >Szymon Trocha wrote:
> >>Maciej Glowiak wrote:
> >>
> >Hello all,
> >
> >let me first introduce: I'm Michael Bischoff I work at surfnet for 
> >perfsonar on the java flow selection and aggregation MA.
> 
> Hi Michael
> >
> >while familiarizing myself with the codebase I noticed how perfsonar 
> >uses only checked exceptions. When these are thrown they are passed 
> >along/bubble up to the message handler which deals with them by 
> >returning an appropriate message to the client. In between code 
> >doesn't handle these exceptions which makes sense. However since the 
> >code in between doesn't handle them why not make PerfSONARException a 
> >unchecked/runtime exception? this would allow the removal of all those 
> >throws 'decorations'. Given that the ServiceEngine's javadoc would 
> >reflect this there shouldn't be any trouble with it. In the cases 
> >(which I haven't encountered), where a checked PerfSONARException 
> >would make sence, I doubt if PerfSONARException is the exception to 
> >throw.
> 
> Very good idea. I think using runtime exception fits in our code perfectly.
> 
> Thanks
> 
> Roman
> 

Regards,
-- 
Uros Juvan
Arnes