perfsonar development work

[Michael Bischoff <>]

Szymon Trocha wrote:
> Maciej Glowiak wrote:
> > Hi,
> >
> > Yesterday I made required changes. I updated a lot of classes because 
> > changing interface "throws" declarations caused compilation problems 
> > in most of classes. I went through all classes and changed 
> > SystemException, DataFormatException, RequestException, etc. to 
> > PerfSONARExceptiopn.
> >
> > You probably got SVN log message, but the mail was quite a long (a 
> > lot of classes changed), so you probably missed it. As it is quite 
> > important I paste the log message below once again:
> >
> > ------------------------------------------------------------------------- 
> >
> > Log:
> > Deprecating old exceptions hierarchy. Now only PerfSONARException 
> > will be used.
> > I deprecated old classes and tried to replace all old exceptions with 
> > the hierarchy-top-exception PerfSONARException, but of course I might 
> > miss some.
> > I didn't have possiblility to test all services and classes, I've 
> > just check them in Eclipse. Anyway, all developers should test their 
> > services.
>
> Hi all,
>
> Could every service's developer check the impact of this change on his 
> service and report to Maciej if any problem occurs?
>
> Thanks and regards,
Hello all,

let me first introduce: I'm Michael Bischoff I work at surfnet for 
perfsonar on the java flow selection and aggregation MA.

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.

anyways, was there there  some rationale behind PerfSONARException being 
a checked exception?

My code is currently outside the repository, but I will make it reflect 
this change before I merge it. Regarding the code that is in the 
repository I saw that javadoc doesn't reflect the change yet (eg @throws 
SystemException  and alike is in quite some spots.)  Eclipse and  
Intellj (and I think netbeans too) support checking of these; in eclipse 
you need to enable it under window > preferences, java > compiler > 
javadoc.

The wiki should be changed to reflect the changes also.

greetings

Michael Bischoff.