If a null Client property is a supported state, consider using a NullObject.
But most likely this is an exceptional state, so you should make it impossible (or just not very convenient) to end up with a null Client:
public Client Client { get; private set; } public Room(Client client) { Client = client; } public void SetClient(Client client) { if (client == null) throw new NotSupportedExceptionArgumentNullException(); Client = client; } If it is not supported however, do not waste time on half baked solutions. In this case:
return Client == null ? 0 : Client.Id; You've 'solved' the NullReferenceException here but at a great cost! This would force all callers of Room.ClientId to check for 0:
var aRoom = new Room(aClient); var clientId = aRoom.ClientId; if (clientId == 0) RestartRoombookingWizard(); else ContinueRoombooking(clientid); Strange bugs can arize with other devs (or yourself!) forgetting to check the "ErrorCode" return value at some point in time.
Play it safe en fail fast. Allow the NullReferenceException to be thrown and "gracefully" catch it somewhere higher up the call stack instead of allowing the caller to mess things up even more...
On a different note, if you are so keen to expose the Client and also the ClientId think about TellDontAsk. If you ask too much from objects instead of telling them what you want to achieve, you may end coupling everything together, making change more difficult later on.