Bug 192178 - [ErrorHandling] Bad error handling in Workbench.runUI()
Summary: [ErrorHandling] Bad error handling in Workbench.runUI()
Status: CLOSED WONTFIX
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.3   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Platform UI Triaged CLA
QA Contact:
URL:
Whiteboard: stalebug
Keywords: helpwanted
Depends on:
Blocks:
 
Reported: 2007-06-12 09:01 EDT by Kim Horne CLA
Modified: 2021-10-21 11:32 EDT (History)
3 users (show)

See Also:
Szymon.Brandys: review? (eclipse)


Attachments
Patch (1.05 KB, patch)
2008-02-18 05:31 EST, Krzysztof Daniel CLA
no flags Details | Diff
mylyn/context/zip (2.59 KB, application/octet-stream)
2008-02-18 05:31 EST, Krzysztof Daniel CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
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.