This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | setDefaultCloseOperation problem | ||
---|---|---|---|
Product: | platform | Reporter: | Jaromir Uhrik <juhrik> |
Component: | -- Other -- | Assignee: | Jaroslav Tulach <jtulach> |
Status: | VERIFIED WONTFIX | ||
Severity: | blocker | CC: | jtulach, mkrauskopf |
Priority: | P3 | ||
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
Jaromir Uhrik
2006-06-01 10:29:21 UTC
see 70145, i've also met this.. I'd argue that core/execution behaves right here. The SecMan just report that exit () is not allowed (and potentially kill the thread group trying to perform exit). It is strange that the JFrame mode setter checks the exit right that early, but the exception would be there after closing the window anyway (but swallowed one). It is questionable whether we should hide the ExitSecurityException in the AWT thread handler (as we're doing now) when the IDE no longer support internal execution. Not hiding it would immediatelly reveal the real problem (=you must not call System.exit() inside the IDE). Reassigning to core/code for evaluation (NbErrorManager does the filtering, cc-ing Yarda) I do not think there is anything else to do. We need to prevent System.exit(0) and we do it using our own security manager. However, the jFrame.setDCO(EXIT_ON_CLOSE) uses the same query and there does not seem to be a way to distinguish between those two calls. Anyway even this one succeded, there would be the exception during closing the frame... Marking issue as VERIFIED. |