Re: Checking for null parameter

"pek" <kimwlias@xxxxxxxxx> wrote in message
news:109cb47e-3b12-4fae-a8fb-443b07af220a@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Jun 9, 1:51 pm, Lew <con...@xxxxxxxxxxxxxxxxxxxxx> wrote:
ttrifonov wrote:
Hi,

It's very bad idea to throw java.lang.Exception for null parameters.
It's better to throw NullPointerException or IllegalArgumentException.
These exception are run-time exception so you don't need to use any
try-catch blocks.

If an exception is thrown, runtime or not, it's a pretty darn good idea
that
the calling code have a catch block for it, if one doesn't take the care
to
pass only valid values in the first place.

Given a method 'foo()' that can throw an IllegalArgumentException, the
best
practice is to pass only valid values to it in the first place:

if ( arg == null )
{
handleNullSituation();
}
else
{
foo( arg );
}

NOW you don't need a try-catch, but if you don't do the pre-check, then
you
absolutely would need to catch the exception.

--
Lew

So, what do you consider a better way of coding? Doing a pre-check,
thus avoiding all your methods to have an exception handling a null
state, or having try catch everywhere?
[ SNIP ]

In Lew's example above it's simply the case that method "foo" expects a
non-null argument by contract. A method like that is under no obligation to
do anything other than throw an NPE if it gets a null argument.

What Lew is pointing out is this: the code that calls "foo" actually has two
valid paths of execution - one, "arg" is null, and two, "arg" is not null.
Let's say that the calling code is in method "bar"...this method considers a
null value of arg" to be legitimate, checks for it, and does
"handleNullSituation" with it. "bar" handles the non-null case by calling
"foo" - as we've said, "foo" does *not* consider a null argument to be
valid.

Let's consider another example, that can see null values in several
different ways. Your method "bar" is using method "get" in interface Map.
This returns null if there is no mapping for the key or the key maps to
null. First note - "get" throws an NPE if the map does not permit null keys
(like Hashtable)...this is an example of a method simply not accepting a
null argument at all. So you potentially have 4 possibilities here:

1) "get" throws an NPE;
2) "get" returns a null and you determine that the key exists;
3) "get" returns a null and the key does not exist;
4) "get" returns a non-null.

Case 1 shouldn't happen, but eventually will. You should be aware of whether
your map does or does not accept null keys - it it doesn't, but *your*
method (namely "bar") could *legitimately* get null keys, check for a null
key and do something else. If your calling code (namely "bar") does *not*
expect to ever get a null value to pass to "get", call "get" all the time,
and if "get" (see below, it's actually "containsKey" that barfs) throws an
NPE just let that percolate up from "bar" as well - whatever called "bar"
wasn't doing what it should have been doing.

Cases 2, 3 and 4 are handled by a construct similar to what Lew has:

if (someMap.containsKey(key)) {
Object obj = someMap.get(key);
if (obj == null) {
// key exists but maps to null
handleNullValue();
} else {
// "foo" expects a non-null argument
foo(key);
}
} else {
// handle situation where key is not mapped at all
handleNonmappedKey();
}

Note that in the above snippet, if the map does not accept null keys, the
snippet itself is behaving like method "foo" - it does not expect null keys
and makes no effort to handle them. In this situation (the map does not
accept null keys) it's up to "bar" to look for them *if* "bar" itself
expects null keys. If even "bar" never expects to see null keys, neither
"bar", the above code snippet, nor "foo" make any effort to check for null
keys...just let the NPE percolate up.

And where the map can accept null keys, the above code snippet behaves
reasonably. Note: if it's for some reason important to you (for a map that
can accept null keys) to differentiate between the key being null and the
key just not being in the map, "bar" can deal with that too (either in the
else block or before the code snippet is reached).

I hope this example helped. To me null handling is a simple question of,
where do you expect to see it, both as arguments and return values? In the
above, depending on the situation, "bar" is potentially doing null checks
both on arguments it gets and on return values from methods it calls, and is
also aware of how the methods it calls handle null arguments. And as I've
indicated, you look for and handle null if you expect to see it...if you
don't, let an NPE happen.

AHS


.

Relevant Pages

  • Re: Output Validation not working
    ... output message validation(not like test map). ... without throwing any exception. ... Microsoft Online Community Support ... where an initial response from the community or a Microsoft Support ...
    (microsoft.public.biztalk.general)
  • Re: Recovering from a Mapping Failure
    ... The problem is if the XML document has many errors. ... idea throw an exception on the first error and interrupt the whole ... exception, so there are several ways to handle this. ... As such the Map has at least a couple of potential failure hotspots (i.e. ...
    (microsoft.public.biztalk.general)
  • Re: BizTalk 2006 :: Mapper problems with XSLT at runtime
    ... We use XSLT over the mapper and have come across a fair few problems, ... Check that the map is actually using the XSLT in the 'Custom XSLT ... Uncaught exception has suspended ... Data at the root level is invalid. ...
    (microsoft.public.biztalk.general)
  • Re: BizTalk 2006 :: Mapper problems with XSLT at runtime
    ... We use XSLT over the mapper and have come across a fair few ... Check that the map is actually using the XSLT in the 'Custom XSLT ... Uncaught exception has suspended ... Data at the root level is invalid. ...
    (microsoft.public.biztalk.general)
  • Re: BizTalk 2006 :: Mapper problems with XSLT at runtime
    ... We use XSLT over the mapper and have come across a fair few problems, ... Check that the map is actually using the XSLT in the 'Custom XSLT ... Uncaught exception has suspended ... Data at the root level is invalid. ...
    (microsoft.public.biztalk.general)