Hi Andreas In order to fix such an issue, one option is creating a utility method, e.g. "static @NonNull Resource getParent(Resource)", check for a null parent inside and throw a RuntimeException of your choice if it is null. Throwing the exception explicitly rather than letting the NPE just happen allows you to find the root cause more easily and, maybe more importantly, to document in the exception message your assumption that "parent" should never be null in your code. Doing this is simple and does actually improve the maintainability of your code (at least IMHO), while satisfying the tool.
Note that I am not saying that tools cannot have "stupid" effects, just trying to give you an option for resolving your issue whilst improving code quality. Regards Julian On Tue, Nov 12, 2019 at 8:40 PM Andreas Schaefer <[email protected]> wrote: > > Hi Angela > > One of the biggest issues I ran into with Null Annotation is that getParent() > can return null when it is the root. > This is fine as in my code I never deal with root but SonarCloud does not > care and flags all of the getParent() calls to have a null check. > Not sure how to fix this but for sure it shows how ’stupid’ tools are if just > applied blindly. > > Cheers - Andy > > > On Nov 12, 2019, at 12:56 AM, Angela Schreiber <[email protected]> > > wrote: > > > > hi sling devs > > > > when writing patches for the repo init recently, i noticed that there is > > some inconsistency in the formatting and that the code doesn't come with > > notnull/nullable annotations, which leads to a quite some extra checks for > > null, though the input will never be null. > > > > having said that: is there an official coding style that i should follow > > when fixing the formatting inconsistencies? are notnull/nullable > > annotiations being used in the sling project? > > > > kind regards > > angela >
