Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 192178

Summary: [ErrorHandling] Bad error handling in Workbench.runUI()
Product: [Eclipse Project] Platform Reporter: Kim Horne <eclipse>
Component: UIAssignee: Platform UI Triaged <platform-ui-triaged>
Status: CLOSED WONTFIX QA Contact:
Severity: normal    
Priority: P3 CC: bokowski, emoffatt, krzysztof.daniel
Version: 3.3Keywords: helpwanted
Target Milestone: ---Flags: Szymon.Brandys: review? (eclipse)
Hardware: All   
OS: All   
Whiteboard: stalebug
Attachments:
Description Flags
Patch
none
mylyn/context/zip none

Description Kim Horne CLA 2007-06-12 09:01:20 EDT
3.3

The try/catch block in runUI() does not handle throwables unlike the try/catch in runEventLoop.  This means that if the advisor or any of the baser init methods dies with an Error Eclipse simply crashes - no error reporting is done.
Comment 1 Krzysztof Daniel CLA 2008-02-18 05:31:32 EST
Created attachment 89964 [details]
Patch

I am not sure if this is enough... But it looks like very trivial change... any comments  are welcomed.
Comment 2 Krzysztof Daniel CLA 2008-02-18 05:31:36 EST
Created attachment 89965 [details]
mylyn/context/zip
Comment 3 Szymon Brandys CLA 2008-02-21 05:55:44 EST
It looks good for me. Kim?
Comment 4 Kim Horne CLA 2008-02-22 11:07:12 EST
Reacting to generic throwables is dangerous.  If it's an OutOfMemory or out of handleor some other type of severe error trying to handle it could also fail.  I'd like to get some more opinions on this.  Boris?  Eric?  You had some pretty interesting ideas about handling catastrophic failures before...
Comment 5 Eric Moffatt CLA 2008-02-25 14:07:45 EST
This is similar to my point in not having a 'generic' flag to allow control of the response to an Error/Warning passed into the StatusManager; we have to at least try to identify 'recoverable' vs 'catastrophic' conditions. 

The current idea is to use the 'code' field to identify the exceptions that we've 'handled' (i.e. those for which our code should continue to work correctly). Then any exceptions that have code == 0 indicate exceptions that we either didn't generate or for which we have no 'answer' except to shut down...

The exact values of the field and the identification of what value to place on each of our generated exceptions is TBD...
Comment 6 Eric Moffatt CLA 2008-02-25 14:12:12 EST
We might look at this as part of bug 218197 which addresses some of the generated exceptions...comments?
Comment 7 Eclipse Webmaster CLA 2019-09-06 16:09:17 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
Comment 8 Eclipse Genie CLA 2021-10-21 11:32:11 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug.

If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.