I initially liked object initializers because of the minimized amount of code it generates.
However, I’ve noticed lately if you are initializing properties and one of them throws an exception, you don’t know which one it was that caused the exception.
eg.
You get an exception but it doesn’t show you what property it was, because an object initializer is actually one line (I know it gets compiled to CIL which uses multiple lines, but according to C# it’s just one line because there’s only one semicolon).
Just wondering what other people’s thoughts are on this?
Is there some way to find out which property initialization caused the exception?
If not, I’m going to stick with the old school syntax, at least that way you know exactly which property caused the exception.
The answers here say you can see the line number in the stacktrace.
You can see a line number, it reports line 11, however this doesn’t help me since an object initializer is just one line of code.
(I know it gets compiled to CIL which uses multiple lines, but according to C# it’s just one line because there’s only one semicolon).
Note that this (you can only set a breakpoint for each semicolon) isn’t always true. If you have a lambda, for example, you can only add a breakpoint for the entire line by clicking on the gutter to the left, but if you right-click inside the line and go to Insert Breakpoint, you can insert the breakpoint for that portion of the line.
For example:
If I click in the gutter, it’ll set a breakpoint for the entire line (and, alas, that breakpoint won’t apply to the lambda!). Let’s remove that one again.
Now, let’s right-click on Contains, and go to Breakpoint, Insert Breakpoint. Now, you have a breakpoint specifically for the lambda!
But, no such luck for property initializers.
Instead, here’s what you do: with the debugger running, you go to the Exception Settings pane and click the checkbox next to Common Language Runtime Exceptions. Then run your code. Now, any try/catch is essentially ignored and the debugger will break on exceptions regardless. If, say, trust.Name.Value causes an NRE, you will see that NRE exactly in that line.
You might want to revert this setting afterwards, though, as it can get quite noisy.
First, to answer your questions, the answer is you can’t. As you point out, it’s all one line. So what do you do? Code defensively so as not to throw a NullReferenceException.
In looking at your code, you could have any one of those properties as null, but trust could also be null. If you were to do this more traditionally, what happens when one of those properties is null? You’re going to have to deal with that some how anyway.
I’m going to make some assumptions about the types of those properties based on their name..
So what if:
You can set whatever values you want after the null coalesce operator ‘??’.
If you need other things to happen and not create a TrustModel, then you will need guard clauses.
And to take it a little further, ensure that the trust object satisfies any invariants it needs to.
You need to decide if you’d want an empty string in Trust name in your TrustModel class if trust.Name is null or if you should throw an exception.
If you want it to throw, then throw when you construct the initial Trust object. That ensures it’s always valid and doesn’t throw when referencing the property later.
/u/backwards_dave1
So what do you do? Code defensively so as not to throw a NullReferenceException.
But that’s kind of orthogonal to the question. You should only write code like you suggest, if that makes sense at runtime. If it doesn’t, it should crash, no matter how good the stack trace is. A NullReferenceException should be considered a coding error anyway.
Just use a debugger? Put a breakpoint on that line and check which values are null…
Sure, but in some cases object initializers could be huge.
In the code base I maintain, we (shouldn’t) have view model initialisers that are 10s of properties long, referencing navigation properties with complex relationships to the underlying model. Luckily a gut feeling is all you need when scanning through.
I think the best course of action is to be defensive, ensure that the objects you’re referencing have already been checked for null assignment or use null propagation operators on said models if you’re not sure, some cases could be more complex.
A little bit of investigating the underlying object can go a long way, especially in the case referenced above.
Generally speaking, if you are adhering to microsofts c# guidelines, properties should not throw exceptions. And then you dont have the problem anymore.
Read up more: https://stackoverflow.com/a/1488488
Also, write tests for your properties if they contain any amount of logic that might fail.
Generally speaking, if you are adhering to microsofts c# guidelines, properties should not throw exceptions. And then you dont have the problem anymore.
That’s not related. In this case, a field or property is likely null, which causes the exception.
Obviously I can’t see all the code so it’s tough to say, check to see if “trust” or it’s property are null before the assignment
Not sure why you got a down vote, because your statement about a null check is correct (although you don’t need to see the rest of the code to answer OP’s question).
This idea of being defensive is powerful when the debugger let’s you down and its a good practice to adopt, especially if your object initializers are large. Whether that’s a null check or the use of null propagation on objects that could be null.
People saying to scan the properties, placing a breakpoint of the line creating the object aren’t wrong, but they haven’t thought about a responsible approach. What if I have 100 properties, referencing many models with complex relationships? Good luck scanning that with no context…
Set the debugger to break on any exception throw (or just on NullReferenceException throw), and run it.
Normally the debugger breaks on unhandled exceptions instead.
Those are terrible answers. It’s clear as day that no matter how you layout the code, the debugger considers object initializers as one line.
Unfortunately, I don’t have good answer either. It is what it is. I ran into this when writing an object mapper that compiles code that reads from a DataReader into an object initializer dynamically at runtime. You just have to look at each assignment.
I considered putting a wrapper around each assignment to be able to catch the exact point the exception happens, but then you don’t want to do that for production code.
The following code works, but ugh.
The point is valid though, make sure you handle those problems outside of object initializers.
Fixed formatting.
Hello, rupertavery: code blocks using triple backticks (“`) don’t work on all versions of Reddit!
Some users see this / this instead.
To fix this, indent every line with 4 spaces instead.
FAQ
You can opt out by replying with backtickopt6 to this comment.
C# devs
null reference exceptions