UnhandledException>>emergencyHan
Locked
UnhandledException>>emergencyHan
 
|
I thought I would ask the question here instead of going to Cincom support as others may run into this issue. In migrating from VW7.4 to VW7.7, I noticed different behavior when using the UnhandledException>>emergencyHandler: method. We use this method to trap all unhandled exceptions and offer users the opportunity to send their exception to ClearQuest for bug reporting. Our code looks something like this:
| ans | UnhandledException emergencyHandler: [:t1 :t2 | ((((((t1 description findString: 'Halt' startingAt: 1) = 0 and: [(t1 description findString: 'StepIntoBlock' startingAt: 1) = 0]) and: [(t1 description findString: 'User Interrupt' startingAt: 1) = 0]) and: [(t1 description findString: 'Break' startingAt: 1) = 0]) and: [(t1 description findString: 'permissions' startingAt: 1) = 0]) and: [(t1 description findString: 'Assertion failed' startingAt: 1) = 0]) ifTrue: [ans := Dialog confirm: ('Exception: ' , t1 description , '. \\Submit problem report before openning exception debugger? \NOTE: Report will be logged into ClearQuest.') withCRs initialAnswer: false]]. Note: This is not the complete block code, but just enough define the problem. In VW7.4, after returning from this block, the debugger would open. In VW7.7 this doesn't happen. We just get into an endless loop with the Dialog. In VW7.4, halt worked fine using this block. In VW7.7 we don't get the halt debugger. The new default behaviour seems to be to 'proceed' without popping up the debugger. The class comment on UnhandledException makes mention of what I'm trying to do here, but not enough detail is provided to help. Is there a better way to do this? Thanks, Mark Petersen |
Re: UnhandledException>>emergencyHan
|
|
What is the unhandled exception that occurs? Would it prevent the
Dialog from coming up due to some change in behavior? Is the first unhandled exception the same as the subsequent unhandled exceptions (assuming the infinite loop is one in which more exceptions occur)? -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of MarkPetersen Sent: Friday, May 07, 2010 7:02 AM To: [hidden email] Subject: [vwnc] UnhandledException>>emergencyHandler: issue with VW7.7 I thought I would ask the question here instead of going to Cincom support as others may run into this issue. In migrating from VW7.4 to VW7.7, I noticed different behavior when using the UnhandledException>>emergencyHandler: method. We use this method to trap all unhandled exceptions and offer users the opportunity to send their exception to ClearQuest for bug reporting. Our code looks something like this: | ans | UnhandledException emergencyHandler: [:t1 :t2 | ((((((t1 description findString: 'Halt' startingAt: 1) = 0 and: [(t1 description findString: 'StepIntoBlock' startingAt: 1) = 0]) and: [(t1 description findString: 'User Interrupt' startingAt: 1) = 0]) and: [(t1 description findString: 'Break' startingAt: 1) = 0]) and: [(t1 description findString: 'permissions' startingAt: 1) = 0]) and: [(t1 description findString: 'Assertion failed' startingAt: 1) = 0]) ifTrue: [ans := Dialog confirm: ('Exception: ' , t1 description , '. \\Submit problem report before openning exception debugger? \NOTE: Report will be logged into ClearQuest.') withCRs initialAnswer: false]]. Note: This is not the complete block code, but just enough define the problem. In VW7.4, after returning from this block, the debugger would open. In VW7.7 this doesn't happen. We just get into an endless loop with the Dialog. In VW7.4, halt worked fine using this block. In VW7.7 we don't get the halt debugger. The new default behaviour seems to be to 'proceed' without popping up the debugger. The class comment on UnhandledException makes mention of what I'm trying to do here, but not enough detail is provided to help. Is there a better way to do this? Thanks, Mark Petersen -- View this message in context: http://forum.world.st/UnhandledException-emergencyHandler-issue-with-VW7 -7-tp2134229p2134229.html Sent from the VisualWorks mailing list archive at Nabble.com. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: UnhandledException>>emergencyHan
|
|
Andres,
For degugging, I simply evaluate 1+'1' and let the exception block do its thing. It's not that the exception block itself generates an exception; just the way it works in different from vw74. Yes, the exception is the same message "Message not Understood". In vw74, the debugger interrupt interface opens after dismissing the dialog, in vw77 it does not. That's the key difference. Thanks, Mark Petersen |
Re: UnhandledException>>emergencyHan
|
|
In reply to this post by Andres Valloud-6
Hmmm, I find it puzzling that this would have given you the
debugger in 7.4. As far back as I can see, the method defaultAction in
UnhandledException checks for an emergency handler, and if it finds one,
returns its result instead of opening a debugger. I suspect that the best
way to approach it is that if you want a debugger, do the Notifier code
that's found after that in the emergency handler itself. Your issue might
also be that somehow it is trying to bring up the debugger, but that code
associated with that has changed, and there are overrides or other things
that rely on the way it was working previously. But that's just
speculation.
At 03:20 AM 2010-05-08, Valloud, Andres wrote: What is the unhandled exception that occurs? Would it prevent the --
Alan Knight [|], Engineering Manager, Cincom Smalltalk
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |