perfsonar development work

[Michael Bischoff <>]

Uros Juvan wrote:
> 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:
> >     
> > >       
> > Very good idea. I think using runtime exception fits in our code perfectly.
> >
> > Thanks
> >
> > Roman
> >
> >     
>
> Regards,
>   
Let me first start of by saying there are two camps in the java world
where both camps are able to back there stories up. This is why I was
wondering if the choice for checked was deliberately made.

"just because you do not want to declare throws statements."

perhaps I explained poorly, the motivation is not laziness. The
motivation is that when I call a method which throws  a
PerfSONARException (or any Exception for that matter) I fell
the need to handle it. What I find is that with respect to
PerfSONARException that I always declare throws because I
have no sensible way of handling the Exception.

Which makes sense because throwing a PerfSONARException is
basically analogous to finishing a request/message. Since a Service
(simplified)purpose is basically handling requests, it's equal to
exiting the serivce. From a service's perspective it's an end point
and as such makes no sense to bother the rest of your code with it.

If you see a service as a component and the MessageHandler and co
as a container then PerfSONARException's are for the container to
handle. And since the container is handling PerfSONARException's It
isn't going to corrupt the Program's state.

If a client cannot do anything to recover from the exception, make it an unchecked 
exception.

and as a service we can't recover, in the exceptional case that we can
I have doubts as to whether the Piece of code that threw it in the first
place should have thrown a PerfSONARException in the first place.

For example PropertiesConfigurationComponent#getProperty(); we can
recover from this by  using a default value.  I have doubts if
PerfSONARException rings true here.  (perhaps is a bad example as I
would probebly go about saying that not finding a property is not so
exceptional to warrant an exception. returning null sounds ok to me.
Especially in the light of convention over configuration. )

Errors are a totally different case is my book as they next to saying
something went wrong (even worse) they also say that all bets are
off concerning integrity. (as in you can't even know what's corrupted
thus can't defend against it.)

In 11.2.2 'Why Runtime Exceptions are Not Checked' of the JLS they
are a bit milder.

The /runtime exception classes/ (|RuntimeException| and its subclasses) are
exempted from compile-time checking because, in the judgment of
the designers of the Java programming language, having to declare
such exceptions would not aid significantly in establishing the
correctness of programs.

If you replace 'the Java programming language' with Perfsonar. and
view Services as components(Programs) that run in a container. your
there.

It's all a matter of perception/perspective.

greetings,

Michael Bischoff.