The JADE 2022 release meets tomorrow’s business demands.
Null exceptions must be up there with the most common runtime issue.
Often these occur when dealing with older persistent data that didn?t have the same validation enforced on it, or object references yet to be populated.
There are various strategies to avoid the exception, all with setbacks. The most common is to guard with null checks, which will always have a place, but in some situations can lead to clutter.
C# introduced syntax of " ?. " which if a null is detected on the variable, no further evaluation of the expression occurs and its result value is null of the end result type.
Sure you still have to remember to use it where needed, but for the benefit of code readability how do these compare:
tbxName.text := customer?.name;
tbxPhone.text := customer?.myContactInfo?.phone;
Vs
tbxName.text := "";
tbxPhone.text := "";
if customer <> null then
tbxName.text := customer.name;
if customer.myContactInfo <> null then
tbxPhone.text := customer.myContactInfo.phone;
endif;
endif;
John Beaufoy
|
HistoricalComments
John Richards 7/11/2017 2:08:53 PM
This is being considered as part of a larger review of the language and compiler. Brian Johnstone 10/10/2017 1:30:33 PM @Ty: Regarding your comment "My concern is that this construct makes it easy to hide data inconsistency/ incompleteness issues." Whether user explicitly codes the <> null check, or they used a ?. construct if it existed, in both cases the code is "hiding a potential data inconsistency" but one of them is just more verbose. While developers could potentially misuse this construct, in situations where they shouldn't really use it, the same approach could be used with the more verbose version as well so I don't see that as being a good justification for not having this construct available in the Jade language. Given the increased readability and the more obvious intent of the code for those situations where it is fully legitimate for the reference to be null, such as when creating a new customer, it would be great to be able to write methods with less boiler-plate code protecting against "expected/allowed" null reference situations. Ty Baen-Price 10/10/2017 8:13:37 AM @Kevin - No, I was specifically addressing the readability issue. John Beaufoy 29/09/2017 11:09:28 AM @Carsten - the ternary operator seems more complimentary, an idea on its own merits perhaps? Felt for this frequent scenario it still carried too much ceremony/clutter. Carsten Schill 28/09/2017 8:09:11 AM Ternary operator would solve the problem in a more generic way and it is not possible to implement your own ternary operator with a function. Kevin Saul 27/09/2017 5:23:24 PM @Ty - In the example given, the separate 'contact info' class could have many pieces of contact details which are reused by many different classes. Are you suggesting it's good practice to have a set of get methods on each of the different classes sharing the contact info class, with a method for each property on the contact info class? John Beaufoy 26/09/2017 6:07:31 PM @Ty - Absolutely 'get' functions have their place too. In your 'get' function however, your 3 lines can become 1? John Beaufoy 26/09/2017 6:00:23 PM @ChrisP - Slight amend on yours now in place. Thanks. Ty Baen-Price 26/09/2017 9:58:49 AM My concern is that this construct makes it easy to hide data inconsistency/ incompleteness issues. I think there must be better ways to address this. If code clarity is your goal, wouldn't a Customer::getPhoneNumber() which performs your null/error checking be clearer than a string of "?."s? Chris Power 22/09/2017 1:35:49 PM The phrase "no further instructions on the line are evaluated" needs to be "no further evaluation of the expression occurs and its result value is null". |
