skip restoring terminals with missing working directory

[danthe1st]

Since we already have M3 now, this may be better for Eclipse 2026-12 but that's a decision for committers.

---

With restoring terminals now properly restoring the working directory, it doesn't really make sense to restore terminals pointing to a directory that no longer exists so this PR skips restoring these terminals (see also #2859).

I also used this chance to extract the logic for restoring a single terminal from the stored connection properties into a method for better readability.

[github-actions]

Test Results

    54 files  ±0      54 suites  ±0   59m 24s ⏱️ + 6m 37s
 4 761 tests ±0   4 739 ✅ ±0   22 💤 ±0  0 ❌ ±0 
12 174 runs  ±0  12 021 ✅ ±0  153 💤 ±0  0 ❌ ±0 

Results for commit b0d0ca8. ± Comparison against base commit 32495fb.

♻️ This comment has been updated with latest results.

[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:

terminal/bundles/org.eclipse.terminal.view.ui/META-INF/MANIFEST.MF
terminal/features/org.eclipse.terminal.feature/feature.xml

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 a68a23466d9ab81c9f84988d54cb8be018ba6f5d Mon Sep 17 00:00:00 2001
From: Eclipse Platform Bot <platform-bot@eclipse.org>
Date: Sun, 30 Aug 2026 14:02:35 +0000
Subject: [PATCH] Version bump(s) for 4.42 stream


diff --git a/terminal/bundles/org.eclipse.terminal.view.ui/META-INF/MANIFEST.MF b/terminal/bundles/org.eclipse.terminal.view.ui/META-INF/MANIFEST.MF
index 9652e27d4a..26ecaadcb4 100644
--- a/terminal/bundles/org.eclipse.terminal.view.ui/META-INF/MANIFEST.MF
+++ b/terminal/bundles/org.eclipse.terminal.view.ui/META-INF/MANIFEST.MF
@@ -2,7 +2,7 @@ Manifest-Version: 1.0
 Bundle-ManifestVersion: 2
 Bundle-Name: %pluginName
 Bundle-SymbolicName: org.eclipse.terminal.view.ui;singleton:=true
-Bundle-Version: 1.1.200.qualifier
+Bundle-Version: 1.1.300.qualifier
 Bundle-Activator: org.eclipse.terminal.view.ui.internal.UIPlugin
 Bundle-Vendor: %providerName
 Require-Bundle: org.eclipse.core.expressions;bundle-version="[3.9.0,4.0.0)",
diff --git a/terminal/features/org.eclipse.terminal.feature/feature.xml b/terminal/features/org.eclipse.terminal.feature/feature.xml
index 044c0b1ba2..276e237b4b 100644
--- a/terminal/features/org.eclipse.terminal.feature/feature.xml
+++ b/terminal/features/org.eclipse.terminal.feature/feature.xml
@@ -2,7 +2,7 @@
 <feature
       id="org.eclipse.terminal.feature"
       label="%featureName"
-      version="1.0.400.qualifier"
+      version="1.0.500.qualifier"
       provider-name="%providerName"
       license-feature="org.eclipse.license"
       license-feature-version="0.0.0">
-- 
2.55.0

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

[danthe1st]

@vogella Would you like to review this?

[vogella]

@vogella Would you like to review this?

Sure. Looks good, except:

Path.of(workingDirectory) can throw InvalidPathException. Why not using new File(workingDirectory).isDirectory()?

[merks]

Path.of(workingDirectory) can throw InvalidPathException. Why not using new File(workingDirectory).isDirectory()?

It is used frequently:

I'm not sure we should be generally suggesting "let's avoid using java.nio" where Path.of is a basic starting point for using those modern APIs.

[vogella]

Path.of(workingDirectory) can throw InvalidPathException. Why not using new File(workingDirectory).isDirectory()?

It is used frequently:

I'm not sure we should be generally suggesting "let's avoid using java.nio" where Path.of is a basic starting point for using those modern APIs.

As an alternative, @danthe1st you need to catch the exception.

[merks]

As an alternative, @danthe1st you need to catch the exception.

Of course that wouldn't hurt, But I also don't think there is a compelling need because the value was used as a working directory. The exception appears to be handled mostly only where user input is involved, i.e., where the user could type anything completely bogus:

[vogella]

As an alternative, @danthe1st you need to catch the exception.

Of course that wouldn't hurt, But I also don't think there is a compelling need because the value was used as a working directory

I disagree, the value is read from persisted memory and so much can go wrong with re-reading as persisted value, encoding, OS updates, moved, etc. Checking the exception or avoiding it is mandatory here.