cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: [RT] Checked exceptions considered harmful
Date Wed, 14 Apr 2004 13:50:51 GMT
Just my two cents:

In general I agree with Bertrand that it's nicer to add
a "throws Exception" to an Interface to tell the user
that something can go wrong.

And we shouldn't forget that some exceptions are treated
differently, for example the ResourceNotFound exception
(that's the reason for the ugly exception handling code
in SourceUtil). This exception is treated by the
sitemap engine differently from other exceptions and
we shouldn't loose this feature.

Carsten 

> -----Original Message-----
> From: Bertrand Delacretaz [mailto:bdelacretaz@codeconsult.ch] 
> Sent: Wednesday, April 14, 2004 3:32 PM
> To: dev@cocoon.apache.org
> Subject: Re: [RT] Checked exceptions considered harmful
> 
> Le 14 avr. 04, à 14:50, Ugo Cei a écrit :
> 
> > ...Are you *really* suggesting that doing:
> >
> > 	public someMethod() throws Exception
> >
> > everywhere is good programming practice?
> 
> Dunno about *everywhere* really, but in interfaces 
> declarations I like it.
> Problem is, when writing an interface people try to guess what kind of
> (checked) exceptions might be thrown, and their guess is 
> usually wrong, which leads to all kinds of ugly tricks.
> 
> So for me it's either unchecked exceptions as you suggest, or 
> a sufficiently generic checked exception to keep options open.
> 
> "throws Exception" is not that much better than unchecked 
> ones, but at least you don't confuse people who might not be 
> aware of the general use of unchecked exceptions that you suggest.
> 
> And they might not be aware of it because Cocon is going to 
> use third-party libraries which *do* use checked exceptions. 
> By not following the usual idiom we'd end up with a mix of two things.
> 
> > ...In the real world, what happens is that your checked 
> exceptions get 
> > either swallowed or rethrown as unrelated types of exceptions
> >
> > Here's a case of the former:
> >
> >                 } catch (HttpException e) {
> >                     if (getLogger().isDebugEnabled()) {
> >                         final String message =
> >                             "Unable to get WebDAV children. Server 
> > responded " +
> >                             e.getReasonCode() + " (" + 
> e.getReason() +
> > ") - "
> >                             + e.getMessage();
> >                         getLogger().debug(message);
> >                     }...
> 
> Won't happen if your method throws Exception, unless I'm 
> missing something?
> 
> > ...And here of the latter:
> >
> >   catch (ParserConfigurationException pce) {
> >     throw new SAXException("Couldn't get a DocumentBuilder", pce);
> >   }..
> 
> Same here, if your method throws Exception you're fine.
> 
> > ...Then you have such gems as methods whose only purpose is to wrap 
> > exceptions around other exceptions in order to conform to 
> the "throws"
> > clause on some interface:...
> 
> eek ;-)
> I fully agree about the uglyness in your example.
> 
> > ...Since, *most* of the time, you have no idea what to do with the 
> > exception you've caught, you might as well overlook it. At least, 
> > you'll save a few lines of code.
> >
> > With your approach, you end up with code like:
> >
> > try {
> >   x.someMethod(); // throws Exception
> > }
> > catch(Exception ignored) {
> >   // TODO: do something with this exception }
> >
> > That is, if you're lucky enough to have programmers put in a TODO 
> > comment in there. And nobody is ever going to remove the "throws"
> > clause...
> 
> Ok, point taken: it's easier for callers to overlook checked 
> exceptions than unchecked ones, is that what you mean?
> 
> > ...To sum it up, there is *NO* guarantee that, by using checked 
> > exceptions, you get more correct code. On the other hand, it is 
> > certain that your code will be more verbose and concerned 
> with doing 
> > things that are not its concern, like catching and rethrowing 
> > exceptions. This just clutters a method's responsibility 
> with extra, 
> > irrelevant instructions...
> 
> You have obviously put a lot of thinking into this, and if 
> everybody does as much I wouldn't have a problem.
> 
> What worries me is that the (mythical) average Cocoon user 
> might get confused by mixing two programming styles: checked 
> exceptions used when interfacing with third-party code (as 
> nearly all blocks do), and unchecked exceptions in 
> Cocoon-specific code, core, etc.
> 
> I think a pragmatic view of checked exceptions might be less 
> confusing.
> 
> > ...I must say that I started this discussion with an open mind, but 
> > the more I think about it, the more I am convinced that 
> Bruce Eckel is
> > right: Java doesn't need checked exceptions, they are a failed 
> > experiment.
> 
> I also respect Bruce Eckel a lot, and he might be right. I'm 
> just wondering about applying this in a radical way here.
> 
> -Bertrand
> 


Mime
View raw message