RE: [OT] How to tell when a project you are on is in trouble

2002-11-22 Thread Andrew Hill 
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]>

Re: [OT] How to tell when a project you are on is in trouble

2002-11-22 Thread Vilya Harvey 
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]>

Re: [OT] How to tell when a project you are on is in trouble

2002-11-21 Thread Mark_StGodard 

Friday-Eve link inspired by "How to tell when a project you are on is in
trouble"...

You may have all seen this before but Jeff's post this morning made me
think of it...

http://mindprod.com/unmain.html

It still kills me...

mark






Jeff Caddel <[EMAIL PROTECTED]> on 11/21/2002 01:01:01 PM

Please respond to "Struts Users Mailing List"
   <[EMAIL PROTECTED]>

To:Struts Users Mailing List <[EMAIL PROTECTED]>
cc:    [EMAIL PROTECTED]

Subject:    Re: [OT] How to tell when a project you are on is in trouble


>
>
>I think (hope?) that it's a joke Andrew. Although the subject line makes
me think that it might be real and therefore very, very worrying.
>
I'm sad to say, it's very real.  He found it debugging a problem that
was coming out in the stacktrace as a NullPointerException.  Since
NullPointerException supports chaining it took 4-5 seconds to find the
line of code causing the NullPointerException and 4-5 hours trying to
unravel what the real cause of the problem was.  Turned out to be an IO
problem (related to permissions I think) where the code was dutifully
catching IOException but just ignoring it and instead re-throwing
NullObjectException.

>>The "architect" of the project a friend of mine is on just unleashed
>>this beauty into the source tree, thought ya'll might get a
>>kick out of it:
>>
>>/**
>>* NullObjectException
>>*
>>* Copyright © 2001,2002 ## Corp.  All rights reserved.
>>* This exception is used if the object must not be null and it is
>>*
>>* @author  #
>>*/
>>public class NullObjectException extends Exception {
>>   // Doesn't have to do anything
>>}
>>
>>Note how neatly this disables nested exception handling!!!
>>Pretty nice eh??
>>
>>
>>Jeff Caddel
>>


--
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]>

Re: [OT] How to tell when a project you are on is in trouble

2002-11-21 Thread Jeff Caddel 


I think (hope?) that it's a joke Andrew. Although the subject line makes me think that it might be real and therefore very, very worrying.


I'm sad to say, it's very real.  He found it debugging a problem that 
was coming out in the stacktrace as a NullPointerException.  Since 
NullPointerException supports chaining it took 4-5 seconds to find the 
line of code causing the NullPointerException and 4-5 hours trying to 
unravel what the real cause of the problem was.  Turned out to be an IO 
problem (related to permissions I think) where the code was dutifully 
catching IOException but just ignoring it and instead re-throwing 
NullObjectException.

The "architect" of the project a friend of mine is on just unleashed
this beauty into the source tree, thought ya'll might get a 
kick out of it:

/**
* NullObjectException
*
* Copyright © 2001,2002 ## Corp.  All rights reserved.
* This exception is used if the object must not be null and it is
*
* @author  #
*/
public class NullObjectException extends Exception {
  // Doesn't have to do anything
}

Note how neatly this disables nested exception handling!!!  
Pretty nice eh??


Jeff Caddel



--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: [OT] How to tell when a project you are on is in trouble

2002-11-21 Thread Kevin . Bedell 




- Original Message -
From: <[EMAIL PROTECTED]>

> > Call me crazy, but I can see how this may be useful.

> You're crazy. :-)

You're right. What was I thinking?





---
This e-mail message (including attachments, if any) is intended for the use
of the individual or entity to which it is addressed and may contain
information that is privileged, proprietary , confidential and exempt from
disclosure.  If you are not the intended recipient, you are notified that
any dissemination, distribution or copying of this communication is
strictly prohibited.  If you have received this communication in error,
please notify the sender and erase this e-mail message immediately.
---



--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: [OT] How to tell when a project you are on is in trouble

2002-11-21 Thread Mark_StGodard 

ditto on Effective Java, its a MUST READ
(When Gosling says this book was useful to him (comments on back of
book)... it says something)

mark




"John Owen" <[EMAIL PROTECTED]> on 11/21/2002 10:13:04 AM

Please respond to "Struts Users Mailing List"
   <[EMAIL PROTECTED]>

To:"Struts Users Mailing List" <[EMAIL PROTECTED]>
cc:

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.
> --
> 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.
>
>
> --
> 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]>








--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: [OT] How to tell when a project you are on is in trouble

2002-11-21 Thread John Owen 
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.
> --
> 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.
>
>
> --
> 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]>

Re: [OT] How to tell when a project you are on is in trouble

2002-11-21 Thread Vilya Harvey 
- 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.
--
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.


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: [OT] How to tell when a project you are on is in trouble

2002-11-21 Thread David Graham 
Generally, methods shouldn't return null they should throw an exception.  If 
I wanted to spend my time checking function return codes I would use C.  
It's perfectly acceptable to have a NoDataAvailableException if that 
describes the problem (NullObjectException describes nothing more than 
NullPointerException).

Also, you can never have a null object.  You either have an object or you 
don't :-).

David






From: [EMAIL PROTECTED]
Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Subject: Re: [OT] How to tell when a project you are on is in trouble
Date: Thu, 21 Nov 2002 10:21:37 -0500




Call me crazy, but I can see how this may be useful.

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.

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.

The problem I would have is that it is not named after a recognizable
business event - it should be named as an application exception that
describes what caused it. Something like: NoDataAvailableException or
whatever describes the actual problem.

On the other hand, this person could just be an idiot - who am I to say? :
->

Kevin







"David Graham" <[EMAIL PROTECTED]> on 11/21/2002 09:44:44 AM

Please respond to "Struts Users Mailing List"
   <[EMAIL PROTECTED]>

To:    [EMAIL PROTECTED]
cc:     (bcc: Kevin Bedell/Systems/USHO/SunLife)
Subject:Re: [OT] How to tell when a project you are on is in trouble


I like how it extends Exception which forces you to catch it.  It seems
like
java has this already...maybe NullPointerException?  At least that's a
RuntimeException.  Can you imagine having to catch all of the situations an
object might be null?  Tell your friend I'm sorry for him :-).

David






>From: Jeff Caddel <[EMAIL PROTECTED]>
>Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: [OT] How to tell when a project you are on is in trouble
>Date: Wed, 20 Nov 2002 22:32:24 -0700
>
>The "architect" of the project a friend of mine is on just unleashed this
>beauty into the source tree, thought ya'll might get a kick out of it:
>
>/**
>* NullObjectException
>*
>* Copyright © 2001,2002 ## Corp.  All rights reserved.
>* This exception is used if the object must not be null and it is
>*
>* @author  #
>*/
>public class NullObjectException extends Exception {
>// Doesn't have to do anything
>}
>
>Note how neatly this disables nested exception handling!!!  Pretty nice
>eh??
>
>
>Jeff Caddel
>
>
>--
>To unsubscribe, e-mail:
><mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail:
><mailto:[EMAIL PROTECTED]>


_
MSN 8 with e-mail virus protection service: 2 months FREE*
http://join.msn.com/?page=features/virus


--
To unsubscribe, e-mail:   <
mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <
mailto:[EMAIL PROTECTED]>







---
This e-mail message (including attachments, if any) is intended for the use
of the individual or entity to which it is addressed and may contain
information that is privileged, proprietary , confidential and exempt from
disclosure.  If you are not the intended recipient, you are notified that
any dissemination, distribution or copying of this communication is
strictly prohibited.  If you have received this communication in error,
please notify the sender and erase this e-mail message immediately.
---



--
To unsubscribe, e-mail:   
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: 
<mailto:[EMAIL PROTECTED]>


_
Protect your PC - get McAfee.com VirusScan Online 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: [OT] How to tell when a project you are on is in trouble

2002-11-21 Thread Kevin . Bedell 



Call me crazy, but I can see how this may be useful.

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.

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.

The problem I would have is that it is not named after a recognizable
business event - it should be named as an application exception that
describes what caused it. Something like: NoDataAvailableException or
whatever describes the actual problem.

On the other hand, this person could just be an idiot - who am I to say? :
->

Kevin







"David Graham" <[EMAIL PROTECTED]> on 11/21/2002 09:44:44 AM

Please respond to "Struts Users Mailing List"
   <[EMAIL PROTECTED]>

To:[EMAIL PROTECTED]
cc:     (bcc: Kevin Bedell/Systems/USHO/SunLife)
Subject:Re: [OT] How to tell when a project you are on is in trouble


I like how it extends Exception which forces you to catch it.  It seems
like
java has this already...maybe NullPointerException?  At least that's a
RuntimeException.  Can you imagine having to catch all of the situations an
object might be null?  Tell your friend I'm sorry for him :-).

David






>From: Jeff Caddel <[EMAIL PROTECTED]>
>Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: [OT] How to tell when a project you are on is in trouble
>Date: Wed, 20 Nov 2002 22:32:24 -0700
>
>The "architect" of the project a friend of mine is on just unleashed this
>beauty into the source tree, thought ya'll might get a kick out of it:
>
>/**
>* NullObjectException
>*
>* Copyright © 2001,2002 ## Corp.  All rights reserved.
>* This exception is used if the object must not be null and it is
>*
>* @author  #
>*/
>public class NullObjectException extends Exception {
>// Doesn't have to do anything
>}
>
>Note how neatly this disables nested exception handling!!!  Pretty nice
>eh??
>
>
>Jeff Caddel
>
>
>--
>To unsubscribe, e-mail:
><mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail:
><mailto:[EMAIL PROTECTED]>


_
MSN 8 with e-mail virus protection service: 2 months FREE*
http://join.msn.com/?page=features/virus


--
To unsubscribe, e-mail:   <
mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <
mailto:[EMAIL PROTECTED]>







---
This e-mail message (including attachments, if any) is intended for the use
of the individual or entity to which it is addressed and may contain
information that is privileged, proprietary , confidential and exempt from
disclosure.  If you are not the intended recipient, you are notified that
any dissemination, distribution or copying of this communication is
strictly prohibited.  If you have received this communication in error,
please notify the sender and erase this e-mail message immediately.
---



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: [OT] How to tell when a project you are on is in trouble

2002-11-21 Thread David Graham 
I like how it extends Exception which forces you to catch it.  It seems like 
java has this already...maybe NullPointerException?  At least that's a 
RuntimeException.  Can you imagine having to catch all of the situations an 
object might be null?  Tell your friend I'm sorry for him :-).

David






From: Jeff Caddel <[EMAIL PROTECTED]>
Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: [OT] How to tell when a project you are on is in trouble
Date: Wed, 20 Nov 2002 22:32:24 -0700

The "architect" of the project a friend of mine is on just unleashed this 
beauty into the source tree, thought ya'll might get a kick out of it:

/**
* NullObjectException
*
* Copyright © 2001,2002 ## Corp.  All rights reserved.
* This exception is used if the object must not be null and it is
*
* @author  #
*/
public class NullObjectException extends Exception {
   // Doesn't have to do anything
}

Note how neatly this disables nested exception handling!!!  Pretty nice 
eh??


Jeff Caddel


--
To unsubscribe, e-mail:   

For additional commands, e-mail: 



_
MSN 8 with e-mail virus protection service: 2 months FREE* 
http://join.msn.com/?page=features/virus


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

RE: [OT] How to tell when a project you are on is in trouble

2002-11-21 Thread Chappell, Simon P 
I think (hope?) that it's a joke Andrew. Although the subject line makes me think that 
it might be real and therefore very, very worrying.

Simon

-
Simon P. Chappell [EMAIL PROTECTED]
Java Programming Specialist  www.landsend.com
Lands' End, Inc.   (608) 935-4526


>-Original Message-
>From: Andrew Hill [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, November 20, 2002 11:41 PM
>To: Struts Users Mailing List
>Subject: RE: [OT] How to tell when a project you are on is in trouble
>
>
>>>"used if the object must not be null and it is"
>Ummm. Surely thats what the java.lang.NullPointerException is for?
>
>-Original Message-
>From: Jeff Caddel [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, November 21, 2002 13:32
>To: [EMAIL PROTECTED]
>Subject: [OT] How to tell when a project you are on is in trouble
>
>
>The "architect" of the project a friend of mine is on just unleashed
>this beauty into the source tree, thought ya'll might get a 
>kick out of it:
>
>/**
> * NullObjectException
> *
> * Copyright © 2001,2002 ## Corp.  All rights reserved.
> * This exception is used if the object must not be null and it is
> *
> * @author  #
> */
>public class NullObjectException extends Exception {
>// Doesn't have to do anything
>}
>
>Note how neatly this disables nested exception handling!!!  
>Pretty nice eh??
>
>
>Jeff Caddel
>
>
>--
>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]>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: [OT] How to tell when a project you are on is in trouble

2002-11-20 Thread Andrew Hill 
>>"used if the object must not be null and it is"
Ummm. Surely thats what the java.lang.NullPointerException is for?

-Original Message-
From: Jeff Caddel [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 21, 2002 13:32
To: [EMAIL PROTECTED]
Subject: [OT] How to tell when a project you are on is in trouble


The "architect" of the project a friend of mine is on just unleashed
this beauty into the source tree, thought ya'll might get a kick out of it:

/**
 * NullObjectException
 *
 * Copyright © 2001,2002 ## Corp.  All rights reserved.
 * This exception is used if the object must not be null and it is
 *
 * @author  #
 */
public class NullObjectException extends Exception {
// Doesn't have to do anything
}

Note how neatly this disables nested exception handling!!!  Pretty nice eh??


Jeff Caddel


--
To unsubscribe, e-mail:

For additional commands, e-mail:



--
To unsubscribe, e-mail:   
For additional commands, e-mail: