Re: handling null pointers/records to functions

[Jim Rogers <jimmaureenrogers@worldnet.att.net>]

"quasar" <quasar@nospam.com> wrote in news:41274733@dnews.tpgi.com.au:

> Hi , I was wondering what is the best way to handle null
> records/pointers passed to functions with a return type that is
> generic? 
> 
> for example in this snippet of code node_ptr_type is a record holding
> a single data value of type Data_Type
> 
> function Data_Part (Node_Ptr : Node_Ptr_Type ) return Data_Type is
> begin
>     if node_ptr /= null then
>         return Node_Ptr.Data;
>     else
>         Put_Line("Node passed to FUNCTION DATA_PART is null");
>         {(**)at this point i do not know what to do... do I terminate
>         the 
> program, do I return some form of null object}
>     end if;
> end Data_Part;
> 
> What is the most recommended way to handle this? Point (**) has got me
> stuck.
> 
>

First, it is good to start thinking in Ada and leave some of the C
and C++ terms for those languages. Node_Ptr_Type is an access type,
not a pointer type.

You have probably noticed that the compiler requires you to define
a return value no matter what path is taken through the conditional
expression.

What should you consider as options? It appears that this function
returns a value from a private data type. In this case, passing a
null value to the function is an error. You can handle that error
by raising an exception, which should be handled in the calling
context. The exception clearly and unavoidably identifies an 
erroneous condition to the calling context. 

If the calling context must handle the exception unless you want
this error to terminate the program. Any unhandled exception will
terminate your program.

You ask about returning some kind of null object. I suggest what 
you might consider here is defining some value of the Data member
to indicate no data. This approach avoids exception handling but
is easier to get wrong at the calling context. The calling 
context must compare all return values with the "no data" value
before proceeding. Failure to do so will propogate bad data
throughout the rest of the program.

The use of exceptions is really much more reliable in this case.

Jim Rogers