global exception handler mechanism
Hi, is there a way to install a global handler for exceptions? Right now if I want to log all exceptions, I use approach from ShoreLine and create a PreDebugAction which is activated when any "unhandled" exception occurs. That would be good enough, however the Debugger has zero knowledge of the exception that is actually occuring, as Exception>>debug passes on only the title. So if I want to get back to the original exception and maybe log it with beacon, I need to do a lot of stack and context shenanigans: MyPreDebugAction>>logException MyLogger runDuring: [ (debugger session interruptedProcess suspendedContext stack detect: [ :context | context receiver isKindOf: Exception ]) receiver emit ] Is there a better way to approach this? Thanks, Peter
Hello, The Sunit-Debugger does a stack search on startup to find the test related exception. It might be good to do it better, especially as the debug process starts from the exception I might be a good idea to actually keep a reference to it. Would there be any downside of Exception>>debug passing a reference to the Debugger? Marcus
On 2 Feb 2018, at 17:19, Peter Uhnák <i.uhnak@gmail.com> wrote:
Hi,
is there a way to install a global handler for exceptions?
Right now if I want to log all exceptions, I use approach from ShoreLine and create a PreDebugAction which is activated when any "unhandled" exception occurs.
That would be good enough, however the Debugger has zero knowledge of the exception that is actually occuring, as Exception>>debug passes on only the title. So if I want to get back to the original exception and maybe log it with beacon, I need to do a lot of stack and context shenanigans:
MyPreDebugAction>>logException MyLogger runDuring: [ (debugger session interruptedProcess suspendedContext stack detect: [ :context | context receiver isKindOf: Exception ]) receiver emit ]
Is there a better way to approach this?
Thanks, Peter
On 5 February 2018 at 10:17, Marcus Denker <marcus.denker@inria.fr> wrote:
Hello,
The Sunit-Debugger does a stack search on startup to find the test related exception.
It might be good to do it better, especially as the debug process starts from the exception I might be a good idea to actually keep a reference to it.
Would there be any downside of Exception>>debug passing a reference to the Debugger?
Marcus
On 2 Feb 2018, at 17:19, Peter Uhnák <i.uhnak@gmail.com> wrote:
Hi,
is there a way to install a global handler for exceptions?
Right now if I want to log all exceptions, I use approach from ShoreLine and create a PreDebugAction which is activated when any "unhandled" exception occurs.
That would be good enough, however the Debugger has zero knowledge of the exception that is actually occuring, as Exception>>debug passes on only the title. So if I want to get back to the original exception and maybe log it with beacon, I need to do a lot of stack and context shenanigans:
MyPreDebugAction>>logException MyLogger runDuring: [ (debugger session interruptedProcess suspendedContext stack detect: [ :context | context receiver isKindOf: Exception ]) receiver emit ]
Is there a better way to approach this?
if you own a process (you creating it) , then it is just a piece of cake, just make a topmost block with #on:do: if you don't own a process (suppose you wanna watch already existing one) , it can be done by injecting own context at the bottom of stack , well, unless there are exception handler(s) upper, that catch any exception(s) before you can see them. I think a much better way would be to watch exceptions even before they being handled, for this, i would override Exception>>#signal and add some kind of logging or notification .. well, anything you see fit. That's, of course, a kind of dangerous, be careful. Do not attempt to throw new exceptions while processing just signaled one, else you'll get infinite recursion :)
Thanks, Peter
-- Best regards, Igor Stasenko.
Hi 2018-02-05 11:00 GMT+01:00 Igor Stasenko <siguctua@gmail.com>:
On 5 February 2018 at 10:17, Marcus Denker <marcus.denker@inria.fr> wrote:
Hello,
The Sunit-Debugger does a stack search on startup to find the test related exception.
It might be good to do it better, especially as the debug process starts from the exception I might be a good idea to actually keep a reference to it.
Would there be any downside of Exception>>debug passing a reference to the Debugger?
Marcus
On 2 Feb 2018, at 17:19, Peter Uhnák <i.uhnak@gmail.com> wrote:
Hi,
is there a way to install a global handler for exceptions?
Right now if I want to log all exceptions, I use approach from ShoreLine and create a PreDebugAction which is activated when any "unhandled" exception occurs.
That would be good enough, however the Debugger has zero knowledge of the exception that is actually occuring, as Exception>>debug passes on only the title. So if I want to get back to the original exception and maybe log it with beacon, I need to do a lot of stack and context shenanigans:
MyPreDebugAction>>logException MyLogger runDuring: [ (debugger session interruptedProcess suspendedContext stack detect: [ :context | context receiver isKindOf: Exception ]) receiver emit ]
Is there a better way to approach this?
if you own a process (you creating it) , then it is just a piece of cake, just make a topmost block with #on:do: if you don't own a process (suppose you wanna watch already existing one) , it can be done by injecting own context at the bottom of stack , well, unless there are exception handler(s) upper, that catch any exception(s) before you can see them.
I added it in Pharo 6: aProcess on: Error do: [:err | err logCr] It works in both cases: when process is not started and when it is already running. I used it to intercept errors of forked processes during test run. It would be cool to add #ensure: in addition.
I think a much better way would be to watch exceptions even before they being handled, for this, i would override Exception>>#signal and add some kind of logging or notification .. well, anything you see fit. That's, of course, a kind of dangerous, be careful. Do not attempt to throw new exceptions while processing just signaled one, else you'll get infinite recursion :)
Thanks, Peter
-- Best regards, Igor Stasenko.
You can also override #defaultAction on Exception, and install a custom UIManager subclass implementing unhandledErrorDefaultAction: (sent by UnhandledError #defaultAction, receives the error as argument). Would be nice(r) if UIManager had a defaultUnhandledErrorActionBlock: setter, but it's not too bothersome creating a subclass. Cheers, Henry -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Am 16.02.2018 um 13:38 schrieb Henrik Sperre Johansen <henrik.s.johansen@veloxit.no>:
You can also override #defaultAction on Exception, and install a custom UIManager subclass implementing unhandledErrorDefaultAction: (sent by UnhandledError #defaultAction, receives the error as argument).
Would be nice(r) if UIManager had a defaultUnhandledErrorActionBlock: setter, but it's not too bothersome creating a subclass.
+1 Norbert
Cheers, Henry
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
participants (6)
-
Denis Kudriashov -
Henrik Sperre Johansen -
Igor Stasenko -
Marcus Denker -
Norbert Hartl -
Peter Uhnák