[Insight-developers] SmartPointer null check

[Miklos Espak]

On Thu, Oct 20, 2011 at 4:46 PM, Williams, Norman K <
norman-k-williams at uiowa.edu> wrote:

> An end user should never see a program exception based on a NULL smart
> pointer.  It is a software defect if they do.
>

I agree. Null pointer derefencing is evil. My question is if it is better if
the
program crashes by segfault if there is such a fault in the software or it
is better
if it prints a stack trace at least.

Catching a null pointer exception is considered a bad practice, I agree.

And what I've discovered during my adventures with gdb, if a program
> detects a problem and throws an exception it can actually make it MORE
> difficult to debug. If you dereference a NULL pointer the program stops at
> the point of execution where the problem occurs. If an exception is thrown
> it unwinds the stack and you can have a difficult time finding the context
> of the error.
>

That is a good argument against throwing an exception. I never used gdb
from command line. I use valgrind to detect segfaults. Otherwise I use an
IDE for debugging.

In this case the place of the erroneous code would be shown in the second
line of the stack trace, wouldn't it? In debug mode, you would even see
the line number where the error occurred.


> *if you know you're going to write a time-consuming inner loop, it would
> probably be a performance win to acquire the regular pointer from the
> Smart Pointer for the duration of the loop.  It might only save a couple
> of instructions per iteration, but the cost of doing so is minimal.
>

Yes, I told the same. For the time consuming operations it is better to use
a
regular pointer. This is an argument on my side, since then the null pointer
check does not cause any computational burden.

Miklos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20111020/8df1c91c/attachment.htm>