Error log on shutdown without stack: "Workspace was not properly initialized or has already shutdown"

[iloveeclipse]

After fixing UILockListener via https://github.com/eclipse-platform/eclipse.platform.ui/issues/56 I see now two other errors appearing in the error log if I shutdown Eclipse with a refresh job running.

One of the errors is from resources plugin and has no stack trace. That must be added to understand the issue.

eclipse.buildId=4.24.0.I20220505-1800
org.eclipse.core.resources
Error
Fri May 06 11:42:02 CEST 2022
Workspace was not properly initialized or has already shutdown.

I plan to push a patch.

[merks]

I think in general any jobs running during shutdown encounter a state that is completely chaotic because some bundles are already stopped but the nothing expects to be working with stopped bundles:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=514960

[laeubi]

There is not really a chaotic state at OSGi shutdown, each bundle is stopped in reverse order according to the startlevel but

• There are alot of static accesses in Platform that are prone to errors both at init and shutdown as there is no way to know the state beside getting thrown an error
• due to the excessive use of lazy loading it often depends on user interaction when something is started
• there is no real definition of "start levels" in the platform, actually the default start level is 4. Karaf uses a much more fine grained start levels with default 100 I think reserved to the "system" and any above for user bundles

[iloveeclipse]

@merks : see discussion on https://github.com/eclipse-platform/eclipse.platform.ui/issues/56. This issue is not important as is, but should help understand what's going wrong now, same as https://github.com/eclipse-platform/eclipse.platform.runtime/issues/50 . Something changed recently, so what we see now worries me.

[laeubi]

so what we see now worries me

I confess I'm more worried about the things we don't see ;-)

E.g I think you see this probably now because we have such code in org.eclipse.core.internal.events.BuildManager.getWorkManager():

private WorkManager getWorkManager() {
    try {
        return workspace.getWorkManager();
    } catch (CoreException e) {
        //cannot happen
    }
  //avoid compile error
  return null;
}

Just wanted to quote Murphy's Law here:

Anything that can go wrong will go wrong

(and also in the most worse way)

So probably you just don't see it (what not means this is the part where it happens!), and one better throws an AssertionError() than add a comment that it cannot happen or remove the exception if it is never thrown. But just as an example we assume it previously would triggered a CoreException this code now might fail with a different exception (that is not hidden) just because the exception type is another one.