This question is not about how to solve the problem but rather why it is there in the first place.
So consider these four lines:
Object myString;
Object myDecimal;
System.debug(String.valueOf(myString));
System.debug(Decimal.valueOf((String) myDecimal));
The first statement will work but the second statement will not and I'm really wondering why? I mean – converting a null value to a different type shouldn't be a problem, right? It's still null after all.
Of course I could easily fix this by having a null check in place:
myDecimal == null ? myDecimal : Decimal.valueOf(myDecimal);
While this will work – I would have to add this to every valueOf
with a null input would also yield a bulk output.
Any ideas?
See also: Date.ValueOf not accepting null
Best Answer
It's a design choice:
String.valueOf
chose to allow anull
argument (presumably generating the string 'null').Decimal.valueOf
chose to report anull
argument as an error; I would guess the thinking there was better to "fail fast" rather than propagate thenull
.To avoid lots of
null
checks, design your code to avoidnull
values by e.g. initializing variables where they are declared. If a value ofnull
has to be allowed, address that in one place only by e.g. not calling other code that requires a non-null
value.See e.g. 10 Tips to Handle Null Effectively; a couple of these are specific to Java but most apply to Apex.