Its quite ok to discuss this here since its Friday today. :-) -----Original Message----- From: Vilya Harvey [mailto:[EMAIL PROTECTED]] Sent: Friday, November 22, 2002 17:45 To: Struts Users Mailing List Subject: Re: [OT] How to tell when a project you are on is in trouble
I've read it and I agree that it's an excellent book. I had a look back through it though and couldn't find anywhere that it mentions throwing exceptions in preference to returning null. It does mention using exceptions in preference to distinguished return values for indicating an error, which is definitely a sensible thing to do. But where null is a valid return value for the method (for instance, a getter method for a bean property that has previously been set to null), that should not throw an exception because it's part of the normal operation of that method. That's what Bloch says too: item 39 in 'Effective Java' is "Use exceptions only for exceptional conditions". This is getting pretty off-topic for the Struts User list though. I'd be happy to continue the discussion away from it; for anyone interested, my email address is in my .sig. Cheers, Vil. -- Vilya Harvey, Consultant [EMAIL PROTECTED] / digital steps / (W) +44 (0)1483 469 480 (M) +44 (0)7816 678 457 http://www.digitalsteps.com/ --Disclaimer-- This e-mail and any attachments may be confidential and/or legally privileged. If you have received this email and you are not a named addressee, please inform the sender at Digital Steps Ltd by phone on +44 (0)1483 469 480 or by reply email and then delete the email from your system. If you are not a named addressee you must not use, disclose, distribute, copy, print or rely on this email. Although Digital Steps Ltd routinely screens for viruses, addressees should check this email and any attachments for viruses. Digital Steps Ltd makes no representation or warranty as to the absence of viruses in this email or any attachments. ----- Original Message ----- From: "John Owen" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Thursday, November 21, 2002 4:13 PM Subject: Re: [OT] How to tell when a project you are on is in trouble > According to "Effective Java", it is a better practice to throw an exception > rather than return null. This book makes for good reading. > ----- Original Message ----- > From: "Vilya Harvey" <[EMAIL PROTECTED]> > To: "Struts Users Mailing List" <[EMAIL PROTECTED]> > Sent: Thursday, November 21, 2002 10:06 AM > Subject: Re: [OT] How to tell when a project you are on is in trouble > > > > ----- Original Message ----- > > From: <[EMAIL PROTECTED]> > > > > > Call me crazy, but I can see how this may be useful. > > > > You're crazy. :-) > > > > > NullPointerException on its own subclasses RuntimeException. This means > > > that you are not required to "catch" runtime exceptions or declare them > > > with a "throws" clause of a method. > > > > Bruce Eckel (author of "Thinking in Java") posted an interesting article > on > > his website a short while back, discussing whether checked exceptions in > > general are actually a good idea. The article is at > > http://www.mindview.net/Etc/Discussions/CheckedExceptions > > if you're interested. I'm still not sure whether I agree with the authors > > conclusions, but it's interesting to think about. > > > > > But there are times where having an object be null may have a meaning > > other > > > than a bug in the code - for example you may read from some third-party > > > library that returns a null object as a valid response. If that happens, > > > you may need to catch it or declare it in a throws clause. > > > NullPointerException won't enforce this becaue it subclasses > > > RuntimeException. > > > > I can see where you're coming from with this, but if null is a valid > return > > value then surely that means it's not an exceptional condition? In that > > case, the right thing to do is to check whether the return value is null > > rather than waiting for an exception to be thrown... > > > > Cheers, > > Vil. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
