Null check for org.eclipse.help.IContext

[SougandhS]

Check whether context is null or not before invoking getText()

Fixes : #1689

[github-actions]

Test Results

 1 893 files  ±0   1 893 suites  ±0   1h 32m 12s ⏱️ + 1m 0s
 4 381 tests ±0   4 357 ✅ ±0   24 💤 ±0  0 ❌ ±0 
13 143 runs  ±0  12 976 ✅ ±0  167 💤 ±0  0 ❌ ±0 

Results for commit d9fec94. ± Comparison against base commit 58864d5.

♻️ This comment has been updated with latest results.

[HeikoKlare]

Is this really the right thing to do? Cancelling an execution somewhere deep inside a method because a value is null for undocumented reasons sounds a bit dangerous. And the affected code is actually related to a bug documented here:

• #858

The referenced issue was introduced by exactly the code that now may lead to a null value. So the proposed change rather seems to work around an issue with the change made in https://bugs.eclipse.org/bugs/show_bug.cgi?id=533828 than adding an actual missing null pointer check.

[SougandhS]

The referenced issue was introduced by exactly the code that now may lead to a null value.

Thank you for the detailed review and context. I agree that introducing a null check here may mask the underlying issue rather than addressing its root cause, especially considering the regression mentioned in bug 533828.

Given that, I'll go ahead and close this PR. It makes more sense to investigate and resolve the underlying cause of the null value instead of working around.

[laeubi]

If the value must not be null at this place, a null check can still be sufficient, e.g using Objects.requireNonNull(context, "describe why it must not be null here");
This is much better than having the code run into a generic NPE...

[SougandhS]

If the value must not be null at this place, a null check can still be sufficient, e.g using Objects.requireNonNull(context, "describe why it must not be null here"); This is much better than having the code run into a generic NPE...

thanks I'll update with this

[eclipse-platform-bot]

This pull request changes some projects for the first time in this development cycle.
Therefore the following files need a version increment:

ua/org.eclipse.help.ui/META-INF/MANIFEST.MF

An additional commit containing all the necessary changes was pushed to the top of this PR's branch. To obtain these changes (for example if you want to push more changes) either fetch from your fork or apply the git patch.

Git patch

From 8c3f63fe82be5f17ab6ee196b758d2eea3d0bac0 Mon Sep 17 00:00:00 2001
From: Eclipse Platform Bot <platform-bot@eclipse.org>
Date: Sat, 7 Jun 2025 14:45:13 +0000
Subject: [PATCH] Version bump(s) for 4.37 stream


diff --git a/ua/org.eclipse.help.ui/META-INF/MANIFEST.MF b/ua/org.eclipse.help.ui/META-INF/MANIFEST.MF
index 1218bc2fd5..7593a41764 100644
--- a/ua/org.eclipse.help.ui/META-INF/MANIFEST.MF
+++ b/ua/org.eclipse.help.ui/META-INF/MANIFEST.MF
@@ -2,7 +2,7 @@ Manifest-Version: 1.0
 Bundle-ManifestVersion: 2
 Bundle-Name: %help_system_plugin_name
 Bundle-SymbolicName: org.eclipse.help.ui; singleton:=true
-Bundle-Version: 4.8.100.qualifier
+Bundle-Version: 4.8.200.qualifier
 Bundle-Activator: org.eclipse.help.ui.internal.HelpUIPlugin
 Bundle-Vendor: %providerName
 Bundle-Localization: plugin
-- 
2.49.0

Further information are available in Common Build Issues - Missing version increments.

[HeikoKlare]

If the value must not be null at this place, a null check can still be sufficient, e.g using Objects.requireNonNull(context, "describe why it must not be null here");
This is much better than having the code run into a generic NPE...

Makes sense. The updated change is fine for me and it fits to your proposal, @laeubi, doesn't it?

[SougandhS]

Thank you @HeikoKlare