Re: Checking for null parameter

On Jun 11, 3:40 am, Lew <con...@xxxxxxxxxxxxxxxxxxxxx> wrote:
pek wrote:
I'm also curious about what you would suggest doing in printLength that
would prevent a crash when a null is passed in. Presumably, i [sic] test for
null, or catch the NullPointerException - but what do i do then? Skip the
printing? Print 0? Print an error message? I'd say that the program is
then behaving incorrectly, which is worse than crashing. Should it throw
an unchecked exception? Then it merely crashes in a different way. Should
it throw a checked exception? What could the calling code do with that
that isn't ultimately also crashing?
You are arguing against points that I have not made and with which I
do not agree. Why would I defend points with which I do not agree?

That is not an answer to his question. What would you do in this
situation? I am also curious. His point, I believe and agree, is
either way you choose to go, you still have to fix the point at which
a null reference is passed, thus, checking for it isn't going to
change anything.

Your statement makes no sense. How can you fix what you can't detect? In
order to fix the null reference, you have to find it, which means you have to
check for it. How else do you find it?

What is the difference of reading what you logged and reading the
stack trace of a NPE? In both cases, you can find it.


I suggest that one catch and log the exception. If you prevent the exception,
which is usually better, then catch and log the illegal situation such as null
input. Then restore the program to valid state, commonly a retry of the
input. Is that not the obvious approach?


How do you prevent an exception? By checking if the object is null
before calling a method? How is that preventing? What will it do after
not calling the method? Inform the user for an abnormal situtation and
then close? Isn't this the same thing as if a NPE was thrown? Why even
bother? Because in any case, your code has a bug. Either way, the
program must end because the method wasn't executaded as it had to.
--
Lew

.

Relevant Pages

  • RE: .NET Runtime 2.0 Error - I need more details...
    ... so if you can not use this event to handle the exception. ... The default event logging behavior of console application is built into ... ConsoleException.Program.Main), calling mscorwks!JIT_Throw ... Microsoft Online Community Support ...
    (microsoft.public.dotnet.framework)
  • Re: MCNGP Constitution, According to Kat
    ... *Calling me with a stupid question - $30 ... *Asking me to walk over to your building to fix the problem - $25/step ... *Spilling coke on keyboard - $25 plus cost of keyboard ... *Dealing with tech support requests for obviously pirated software - ...
    (microsoft.public.cert.exam.mcse)
  • Re: Assertion on Type conversion
    ... The author states that "if a method has specified some pre-condition then the failure of that condition is the responsibility of the ... depends on the caller's ability to check for conditions, and assure them to be correct, prior to the calling of the method. ... An overlooked exception that could be handled gracefully. ... Implement a method like "IsValid" to do a runtime check first if your concerned about the ArgumentException being thrown. ...
    (microsoft.public.dotnet.languages.csharp)
  • RE: Microsoft.XLANGs.RuntimeTypes.InvalidPropertyTypeException
    ... Trying to access a data property on a message for which it has not ... Yes the exception is of significant concern; it is a major user error. ... Any exception thrown could delay the cleanup of resources, ... System.Text.StringBuilder.Append), calling mscorsvr!Ordinal76+0x1d925 ...
    (microsoft.public.biztalk.server)
  • Microsoft.XLANGs.RuntimeTypes.InvalidPropertyTypeException
    ... they still occur when we turn tracking off. ... Is this 'exception' of a significant concern? ... System.Text.StringBuilder.Append), calling mscorsvr!Ordinal76+0x1d925 ...
    (microsoft.public.biztalk.server)