Re: [Clirr-devel] exceptions: general philosopy, actual use

[<lak...@t-...>]

Simon Kitching wrote:

>Hi,
>
>I notice that Checker.java is throwing ant.BuildException in places.
>
>  
>

That's a bug, the core should have no dependency on any class of a 
particular frontend.

>I think it would be nice to remove this dependency by having Checker
>methods throw a CheckerException class, and have the AntTask class catch
>these and throw BuildException.
>
>  
>

Yes, that would be much better.

>In particular, the net.sf.clirr.cmdline.CheckRunner class I have just
>written ends up having to catch ant.BuildException if this is not done,
>which feels wrong.
>
>I also see that clirr classes tend to throw "unchecked" exceptions
>(subclasses of RuntimeException) rather than checked exceptions.
>Examples: ant.BuildException, IllegalArgumentException. Is this a
>deliberate design philosophy, or just something that happened?
>
>  
>

IllegalArgument is deliberate - the caller is doing something wrong and 
the only way we can handle it is by throwing an Exception. However, 
correct callers don't want to mess around with exception handling on 
every call in this case, so we throw an unchecked exception.

Throwing a BuildException is not deliberate. For example, the client (in 
this case the Ant task implementation) cannot prevent IOExceptions while 
we are reading the jars. So the client should really be prepared to 
handle IO errors (which would be signalled by a CheckerException, not 
IOException).

This leads to the problem of Exception chaining. When I catch the 
CheckerException, I want to see that IOException in the stack trace 
("caused by ..."). I'm seeing more and more examples where JDK 1.4 would 
be really helpful (regexps for ClassSelector would be another one).

I am aware that there are ways to solve these issues by using 
commons-lang, ORO, etc. - but I'd really like to avoid having all these 
dependencies around and simply require 1.4.

Simon, could you please find out whether it's OK to use JDK 1.4 during 
the build process of our main Apache target projects (commons-*, maybe 
log4j)?

>I am aware that many languages favour unchecked exceptions (.NET, c++)
>but when working in Java I tend to prefer checked exceptions, because it
>is the "norm" for Java code if nothing else.
>
>  
>

Yes, I'm not in the "unchecked exceptions everywhere" camp either - I 
dont have any hard rules, but I decide on an individual basis.

>So:
>* is framework.CheckerException a reasonable name/package?
>  
>

Yes.

>* is it ok to make it a checked exception (subclass Exception)
>  rather than an unchecked one (subclass RuntimeException)?
>  
>

Yes.

>* is net.sf.clirr.cmdline.CheckRunner a good name/package for the 
>  command-line interface?
>  
>

I had net.sf.clirr.cmdline.Clirr in mind. Choose whatever you like best.

Cheers,
Lars