471,347 Members | 1,841 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,347 software developers and data experts.

Returning nulls

Whats the common/best practice for returning a "Does not exist/not
found" result from a function. Imagine I've got a function:

myObjectType GetById(long id);

where the object may or may not be found. Currently, I just return a
null. But this muddies up the calling code with null checks and stuff.
Example:
I've got an Appoinment class, that has a property Doctor of class
Doctor. This property is lazily loaded, so I only store the id of the
doctor in the Appointment class (doctor_id).

public property Doctor Doctor{
get{
if(doctor == null){doctor =
DoctorManager.GetById(doctor_id)}
return doctor;
}
set{
doctor = value;
if(value != null){doctor_id = value.id;}
else{doctor_id = 0;}
}
}

Now, when using the Doctor property in Appointment class, I always have
to check if the Doctor is null. This can be ugly when doing something
like displaying the Appointment information.

private void showAppointment(Appointment apt){
txtTime.Text = ...
if(apt.Doctor != null){
txtRoom.Text = apt.Doctor.OfficeNumber;
txtDoctorName.Text = apt.Doctor.Name;
}
etc...
}

I was thinking of creating a static Doctor instance in the Doctor class
that represents a Null Doctor like this:
public class Doctor{
public static readonly Doctor NullDoctor = new Doctor("Null
Doctor name", "Null Doctor Office",...);
...
}

and in the GetById() functions, returning the NullDoctor if none is
found. This of course, would cause me to change my Doctor Property to
something like this:
public property Doctor Doctor{
get{
if(doctor == null || doctor = Doctor.NullDoctor)
{doctor = DoctorManager.GetById(doctor_id)}
return doctor;
}
set{
doctor = value;
if(value != null){doctor_id = value.id;}
else{doctor_id = 0;}
}
}

Pros/Cons for each approch?

Feb 16 '06 #1
1 1594
SP

<an*************@gmail.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...
Whats the common/best practice for returning a "Does not exist/not
found" result from a function. Imagine I've got a function:

myObjectType GetById(long id);

where the object may or may not be found. Currently, I just return a
null. But this muddies up the calling code with null checks and stuff.
Example:
I've got an Appoinment class, that has a property Doctor of class
Doctor. This property is lazily loaded, so I only store the id of the
doctor in the Appointment class (doctor_id).

public property Doctor Doctor{
get{
if(doctor == null){doctor =
DoctorManager.GetById(doctor_id)}
return doctor;
}
set{
doctor = value;
if(value != null){doctor_id = value.id;}
else{doctor_id = 0;}
}
}

Now, when using the Doctor property in Appointment class, I always have
to check if the Doctor is null. This can be ugly when doing something
like displaying the Appointment information.

private void showAppointment(Appointment apt){
txtTime.Text = ...
if(apt.Doctor != null){
txtRoom.Text = apt.Doctor.OfficeNumber;
txtDoctorName.Text = apt.Doctor.Name;
}
etc...
}

I was thinking of creating a static Doctor instance in the Doctor class
that represents a Null Doctor like this:
public class Doctor{
public static readonly Doctor NullDoctor = new Doctor("Null
Doctor name", "Null Doctor Office",...);
...
}

and in the GetById() functions, returning the NullDoctor if none is
found. This of course, would cause me to change my Doctor Property to
something like this:
public property Doctor Doctor{
get{
if(doctor == null || doctor = Doctor.NullDoctor)
{doctor = DoctorManager.GetById(doctor_id)}
return doctor;
}
set{
doctor = value;
if(value != null){doctor_id = value.id;}
else{doctor_id = 0;}
}
}


Null Object is a common pattern. It encapsulates the behavior expected when
there is no object and eliminates special null handling code that is
scattered throughout your software. If implemented you would eliminate the
== null checks and either check the IsNull property or do no checking at
all. This is because the null object should act correctly, e.g. it's ID
would be 0 as that is the behavior you have decided you want with the
current "null". You will still use the == null checking for your lazy
loading as it is an indicator that no object has been created. However the
object that is created may be a real Doctor or a Null Doctor (there is no
Doctor with that ID). Therefore == null and myDoctor.IsNull are not the same
and mean very different things.

Refactoring by Martin Fowler has a few pages on this.

SP

Feb 16 '06 #2

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Dan Perlman | last post: by
3 posts views Thread by aaj | last post: by
6 posts views Thread by mike | last post: by
6 posts views Thread by Josh Close | last post: by
reply views Thread by anonymous.user0 | last post: by
reply views Thread by Ronak mishra | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.