NullReferenceException or ArgumentNullException

Bug Hunting and NullReferenceException

brute forced brilliance — Thu, 21 Feb 2008 20:17:47 GMT

Bug Hunting and NullReferenceException

Testing the

Peli's Blog — Wed, 21 Jul 2004 14:34:00 GMT

Testing the

Peli's Blog — Wed, 21 Jul 2004 14:32:00 GMT

re: NullReferenceException or ArgumentNullException

Aleksei Guzev — Tue, 20 Jul 2004 09:04:00 GMT

Note that in many cases signals do not propagate father than the direct caller of the signaling method. Unlike exceptions which often bubble up to the operating system.

re: NullReferenceException or ArgumentNullException

Aleksei Guzev — Tue, 20 Jul 2004 04:08:00 GMT

Kannan: I see You do use signal-style. Actually You have posted the previous message while I was typing my last one ;)

It's not my design. I was too young when the design had been used already.

Yes, differentiating between signals and exceptions is a performance hack. I admit, I use a lot of performance hacks. Sometimes performance hacks are essentially what they pay for.

They say exceptions are good and we like them, but this technique affects performance. Perfomance degradation is the reason which I am hearing for decades. Read the comments to this post.

On the other hand if we want different map objects behave differently, then we have to create defferent map classes - one for each behaviour. Just as we do for List and Queue. The chances are those variants of map will be derived from Map and override virtual Map.LookUp method ;) One map should signal while another throws exceptions. If Your task states that absence of a value for the given key is a logical error then you should use the class which throws. But when You create something like cache and have to create an object if it's not present in the hashtable, then You will use the class which signals.

I think, the class libraries and .NET itself should support as many programming styles as possible. Having a lot af classes is not really a problem.

Another solution is including possible signals in signature of the LookUp method, then we could overload methods with changing signal types and count only. Something like this.

// this method throws exception
Map.LookUp(K key);
// while this signals
Map.LookUp(K key) signals(NotFound);

This will reduce the count of classes in the library, but actually I don't like this.

Slightly different classes with good static methods for convertion between then seems being a good solution.

re: NullReferenceException or ArgumentNullException

Kannan Goundan — Mon, 19 Jul 2004 23:23:00 GMT

Aleksei:

Though I do use signal-style exceptions. In Java, it's just a matter of deriving from Throwable and eliminating the stack trace generation. The only reason I use them is for speed. I can't think of any other reason to have two types of "throwable" objects. So, in essence, it's a performance hack that leaks into your design.

Take Map.Lookup(), for example. Should you throw an exception or a signal upon lookup failure? That depends entirely on how the map is being used and so it's difficult for the writer of the Map class to make the decision.

Also, providing a signal class might encourage premature optimization and you'll end up without stack traces. Though it would be possible to provide the line of code that caused the exception, a lot of the time you're going to get something useless like "MapDefaultImpl._CachedSubtreeLookup(): 103".

A half-solution would be to make signals like checked exceptions so at least the programmer is somewhat aware of where the exception could happen.

re: NullReferenceException or ArgumentNullException

Aleksei Guzev — Mon, 19 Jul 2004 04:24:00 GMT

But there is need to leave a method without returning any object. Let's turn our heads backward. We already have large systems providing low-level (sometimes hardware) support for strong typed programming languages. Those systems often use both exceptions and signals. While exceptions have been for exceptional stuff, signals are lightweight variants to work in the situations I had described. The signals can be optimized for frequent use while exceptions could provide detailed stack trace and other error information.

Maybe introducing signals in later verions of .NET will not affect existing code, the more especially as .Net provides side-by-side execution ;)

re: NullReferenceException or ArgumentNullException

Kannan — Mon, 19 Jul 2004 04:19:00 GMT

James:

I'm assuming your three posts were in response to my post about peformance (with throwing exceptions on lookup failures).

1. I'm not sure I understand what you're saying here. Throwing two exceptions can't be faster than throwing one.

2. Yes, the stack trace is handy. That's why it's hard to eliminate it. What I was hoping for is a JIT that can detect when a stack trace is never accessed.

3. One of the reasons exceptions are for "exceptional" events is because they are inefficient. If they weren't, you'd be able to use them more often. The hash lookup failure is an example of a place where an exception would be "cleaner" but was avoided for practical purposes. I once wanted to use exceptions all over the place so I created a "Signal" subclass of "java.lang.Throwable" and nulled out the call that generates the stack trace. It would be nice if I didn't have to do this stuff explicitly (since it now introduces the difficult issue of "should I throw an exception or a signal?").

re: NullReferenceException or ArgumentNullException

James Bellinger — Mon, 19 Jul 2004 02:27:00 GMT

Actually, a smart thing that could be done WRT the stack trace...

One could have some sort of flag bit on each exception handler down the chain which says if it accessed the stack trace, with the assumption for complex things the JIT doesn't want to investigate being 'yes'... most exception handling is pretty simple stuff, at least within the catch { } block, so this might be feasible. Though, exceptions really are supposed to be for *exceptional* stuff, so there's really no reason to optimize them in my opinion. Like NullReferenceException/ArgumentNullException. If you get those, you're done. The End. Fix your code. I can't really think of any exceptions which aren't like that.

Speaking of exceptions, I must say the liberal use of them is one of the best features of .Net. Using ordinary Win32, one finds that tons of methods don't provide much if any information about what on earth is wrong, leading one to just get mad and do something else unless dealing with the problem is a requirement in the short term. Managed DirectX has this flaw, in that it throws DirectXExceptions which are completely useless and non-descriptive. I hope they fix it at some point.

re: NullReferenceException or ArgumentNullException

James Bellinger — Mon, 19 Jul 2004 02:23:00 GMT

The stack trace is really handy a lot of the time, in my opinion. One might want to catch an exception and log it, to send to a developer or whatnot, for instance.