From 9ac3fdfc0e97ff07444a06346e587608f0eafc86 Mon Sep 17 00:00:00 2001 From: Marco Kaufmann Date: Fri, 11 Oct 2024 17:14:55 +0200 Subject: [PATCH] Create rule S7126 --- rules/S7126/java/metadata.json | 8 +- rules/S7126/java/rule.adoc | 153 ++++++++++++++++++++++++++++----- 2 files changed, 136 insertions(+), 25 deletions(-) diff --git a/rules/S7126/java/metadata.json b/rules/S7126/java/metadata.json index c7ec94801a1..7fd3f996a00 100644 --- a/rules/S7126/java/metadata.json +++ b/rules/S7126/java/metadata.json @@ -1,5 +1,5 @@ { - "title": "FIXME", + "title": "Nullable typed expressions should not be used in non-nullable input positions", "type": "CODE_SMELL", "status": "ready", "remediation": { @@ -11,14 +11,12 @@ "defaultSeverity": "Major", "ruleSpecification": "RSPEC-7126", "sqKey": "S7126", - "scope": "All", + "scope": "Main", "defaultQualityProfiles": ["Sonar way"], "quickfix": "unknown", "code": { "impacts": { - "MAINTAINABILITY": "HIGH", - "RELIABILITY": "MEDIUM", - "SECURITY": "LOW" + "RELIABILITY": "HIGH" }, "attribute": "CONVENTIONAL" } diff --git a/rules/S7126/java/rule.adoc b/rules/S7126/java/rule.adoc index 4172043c9d3..3775c143f21 100644 --- a/rules/S7126/java/rule.adoc +++ b/rules/S7126/java/rule.adoc @@ -1,44 +1,157 @@ -FIXME: add a description - -// If you want to factorize the description uncomment the following line and create the file. -//include::../description.adoc[] - == Why is this an issue? -FIXME: remove the unused optional headers (that are commented out) +Using nullable typed expressions in a non-nullable input position (e.g., as the right-hand side of an assignment, a function call argument, or a return statement argument) can lead to a NullPointerException (NPE) at runtime. This occurs because the receiving code typically assumes the value is non-null and omits null checks. -//=== What is the potential impact? +Formally, non-nullable and nullable versions of a type are distinct, with different domains. +The domain of a non-nullable type is _D_, while the domain of a nullable type is _D ∪ null_, a superset of _D_. +Thus, a non-null value can be used wherever a nullable type is expected, but not vice versa. +The only reason it's allowed by the compiler is that null-safety is not a built-in Java language feature, and it's therefore handled via nullability annotations by external tools bypassing the regular typing system. == How to fix it -//== How to fix it in FRAMEWORK NAME + +Depending on the use-case, there are different strategies to fix this problem. === Code examples +**1. Change the input position type from non-nullable to nullable, or the expression type from nullable to non-nullable:** This resolves the issue at the reported location but may propagate it elsewhere. Note: you should avoid declaring everything nullable; only do so where it aligns with your data and state models. Otherwise, consider the other approaches. + ==== Noncompliant code example [source,java,diff-id=1,diff-type=noncompliant] ---- -FIXME +@NonNull String title = createTitle(); + +@Nullable static String createTitle() { + // ... +} ---- ==== Compliant solution [source,java,diff-id=1,diff-type=compliant] ---- -FIXME +@Nullable String title = createTitle(); + +@Nullable static String createTitle() { + // ... +} +---- + +==== Noncompliant code example + +[source,java,diff-id=2,diff-type=noncompliant] +---- +@NonNull String title = createTitle(); + +@Nullable static String createTitle() { + // ... +} +---- + +==== Compliant solution + +[source,java,diff-id=2,diff-type=compliant] +---- +@NonNull String title = createTitle(); + +@NonNull static String createTitle() { + // ... +} +---- + +==== Noncompliant code example + +[source,java,diff-id=3,diff-type=noncompliant] +---- +@NullMarked +class Collector { + void collectData(List entities) { + // ... + } +} + +void process(@Nullable List entities) { + collector.collectData(entities); +} +---- + +==== Compliant solution + +[source,java,diff-id=3,diff-type=compliant] ---- +class Collector { + void collectData(@Nullable List entities) { + // ... + } +} -//=== How does this work? +void process(@Nullable List entities) { + collector.collectData(entities); +} +---- -//=== Pitfalls +**2. Replace `null` case with a guard element:** This is particularly effective for array and collection types, where `null` can easily be replaced with an empty array or collection instance. -//=== Going the extra mile +==== Noncompliant code example + +[source,java,diff-id=4,diff-type=noncompliant] +---- +@NullMarked +class Collector { + void collectData(List entities) { + // ... + } +} + +void process(@Nullable List entities) { + collector.collectData(entities); +} +---- + +==== Compliant solution + +[source,java,diff-id=4,diff-type=compliant] +---- +@NullMarked +class Collector { + void collectData(List entities) { + // ... + } +} +void process(@Nullable List entities) { + var nonNullEntities = entities != null? entities: List.of(); + collector.collectData(nonNullEntities); +} +---- + +**3. Throw an Exception in `null` case:** For unexpected or uninitialized values or unspecified behavior, throw an exception instead of returning `null`. This reports the issue at its origin, not somewhere else in the source code where the unexpected `null` value suddenly becomes a problem. This makes debugging easier. + +==== Noncompliant code example + +[source,java,diff-id=5,diff-type=noncompliant] +---- +@Nullable Element getOrNull() { + // ... +} + +@NonNull Element get() { + var element = getOrNull(); + return element; +} +---- + +==== Compliant solution + +[source,java,diff-id=5,diff-type=compliant] +---- +@Nullable Element getOrNull() { + // ... +} -//== Resources -//=== Documentation -//=== Articles & blog posts -//=== Conference presentations -//=== Standards -//=== External coding guidelines -//=== Benchmarks +@NonNull Element get() { + var element = getOrNull(); + if (element == null) throw new NoSuchElementException(); + return element; +} +---- \ No newline at end of file