Tag Info

New answers tagged

1

As of c# 6.0, which is now released, you should just do this, public class Room { public Room(Client client) { this.Client = client; } public Client Client { get; } } public class Client { public Client(long id) { this.Id = id; } public long Id { get; } } Raising a property of Client to Room is an obvious ...


2

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) { ...


17

I disagree with all three of the opinions. If Client can never be null, then don't even make it possible for it to be null! Set the value of Client in the constructor Throw an ArgumentNullException in the constructor. So your code would be something like: public class Room { private Client theClient; public Room(Client client) { ...


5

The second and third options should be avoided - the getter should not smack the caller with an exception they have no control over. You should decide whether Client can ever be null. If so, you should provide a way for a caller to check whether it is null before accessing it (e.g., bool ClientIsNull property). If you decide that Client can never be null, ...


21

Just a few considerations: a) Why is there a getter specifically for the ClientId when there's already a public getter for the Client instance itself? I don't see why the information that the ClientId is a long has to be carved in stone in the signature of Room. b) Regarding the second opinion you could introduce a constant Invalid_Client_Id. c) Regarding ...


23

It smells like you should limit the number of states your Room class can be in. The very fact that you're asking about what to do when Client is null is a hint that Room's state space is too large. To keep things simple I wouldn't allow the Client property of any Room instance to ever be null. That means the code within Room can safely assume the Client ...


1

Exceptions have been created as a tool to signal exceptional non-fatal conditions up the call chain. That is, they are not designed as a debugging tool. If a null-pointer exception were a debugging tool, it would abort program execution right on the spot, allowing a debugger to connect, pointing it right at the incriminating line. This would give the ...


0

If you wanted to go with @stijn's answer and put null checks in your code, this code snippet should help. Here's some info about code snippets. Once you have this set up, just type argnull, hit tab twice, and then fill in the blank. <CodeSnippet Format="1.0.0"> <Header> <Title>EnsureArgNotNull</Title> ...


0

One can look at state from three points: The state-space the underlying machine provides. The state-space the language provides. The state-space the program-logic allows. In "safe" languages, the first one can generally be disregarded. Though it's good for things like boolean values that are neither true nor false. Haskell for example allows you to ...


2

I think you are missing several other options. For example, you could use a language which doesn't have null. Haskell, Ruby, Smalltalk, many others simply don't have null references, so the problem doesn't even arise. Another option would be to use a language which does have null but has explicit null tracking that allows you to statically ensure that you ...


4

You are mixing stuff. If it can be null, it will be null That means that any value/object that can be null your code needs to deal with gracefully. Three camps? Not know where it came from? Wrong. There is one camp: test for null for any nullable type and deal with it gracefully. If null is not valid you throw an exception and yes you know ...



Top 50 recent answers are included