groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ocs@ocs" <...@ocs.cz>
Subject suggestion: ImplicitSafeNavigation annotation
Date Tue, 14 Aug 2018 11:28:01 GMT
Gentlemen,

some NPE-related problems of today brought me to re-interate one of my older suggestions.

We have the so-called “safe navigation”[*], which in some cases allows a null to be propagated
out of an expression instead of throwing a NPE. At the moment, it can be triggered for a particular
sub-expression (like property/method-call and, as of 3, newly also indexing) using a question
mark (e.g., “foo?.bar()” or “foo?[bar]”).

Do please correct me if I am wrong, but far as I know, there still are expressions which do
not allow the “safe mode”, e.g., arithmetic (“a+b” etc). Furthermore, there are cases
when one simply wants a bigger block of code to contain only null-propagating expressions
and never NPE; in such case, using the question mark syntax is both inconvenient and error-prone
(for it is very easy to forget one of the lot of question marks needed in such a code, and
then get an uncaught unwanted NPE).

For these reasons, I would suggest adding a new annotation, whose name might be e.g., “ImplicitSafeNavigation”;
it would simply force a null-propagation to be implicitly and automatically used for *all*
expressions in the annotated scope, i.e., NPE would never be thrown for them; for example:

===
@ImplicitSafeNavigation class Foo {
 static foo(a,b,c,d,e) {
   a.bar+b*c[d]<<e.bax() // just e.g.; would work with *any* expression which NPEs today
 }
}
assert null == Foo.foo(null,null,null,null,null)
===

I wonder whether this enhancement would be possible to implement in some forthcoming Groovy
release? Myself, I believe it would help tremendously.

If feasible, then it is for a further discussion whether in the scope of this annotation
(a) a safe-navigation syntax (“foo?.bar”) should be ignored as superfluous;
(b) or, whether in this scope it should reverse the behaviour to trigger an NPE anyway;
(c) or, whether it should be ignored as (a), and aside of that it would be worth the effort
(and technically possible) to add another syntax to force NPE over a particular sub-expression
(e.g., “foo!.bar”).

Thanks and all the best,
OC

[*] The name might not be quite apt, for propagating a null is not inherently safer than NPEing;
those are simply two different approaches, both of which serve best in different circumstances.
A better name would be something like “null-propagating” or “non-NPE” mode, I guess.
Myself, I don't think we should change the name though, for all are used to it.


Mime
View raw message