Smalltalk › Instantiations

8.5.2/Seaside: WAExceptionHandler misses instance-based exceptions

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

8 messages Options

jtuchel

8.5.2/Seaside: WAExceptionHandler misses instance-based exceptions

This one is really bad.

In my Seaside Application I had plugged a subclass of WAHtmlError handler into my application in order to display an error page in case of exceptions instead of just crashing the application. This subclass did its job - but not every time. My packaged image would sometimes just crash and write a walkback log. Crashing is not in the scope of tolerable behaviors for a web server so I started digging a little. I found out my Error handler was simply ignored by Seaside in some cases. Without digging in the debugger I came to the conclusion this might be related to the instance-based exceptions in VAST, which Instantiations doesn't suggest to use any more, but still does in VAST, like in Object>>error:

So it turns out Seaside is not configured to catch ExAll or ExError in WAErrorHandler subclasses.

The fix, as far as I found out, is to change WAErrorHandler class>>exceptionSelector to:

exceptionSelector

^ super exceptionSelector, Error, Warning, ExError

Could someone at Instantiations please approve this fix and make sure it makes its way into Seaside asap? Would it be better to add ExAll rather than ExError? This would include Breakpoints, IIUC.

Please also think about whether WAErrorHandler or WAExceptionHandler would be the better place for it.

I temporarily solve this by adding it to my subclass of WAHtmlErrorHandler to avoid too much effort in migrating to newer Seaside base versions, but I wouldn't say that is a good solution. Catching errors in VAST's Seaside port should work exactly the way it does on other Smalltalks out of the box.

This is really an annoying (and dangerous) bug, and since Instance Based Exceptions are very VAST specific, this will probably never be integrated into Seaside base code. If there is a need to move this whole exceptionSelector thing into Grease ore some portability applications, please take the responsibility to coordinate this with the Seaside project.

BTW, while we're at it: is there some kind of schedule when Instantiations ships a version of VAST that completely works with Class based exceptions? I mean, a possible fix for the problem could also be to rewrite methods like Object>>#error: to use Class Based exceptions. That would sure be the cleanest fix for this bug (not taking into account the amount of existing legacy code at customers).

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/pULxeDShvO0J.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

jtuchel

Re: 8.5.2/Seaside: WAExceptionHandler misses instance-based exceptions

It seems my suggested fix doesn't work. I need to investigate a bit further.

The only thing that seems to really work is to avoid throwing instance based exceptions, which is not always possible because methods like Object>>error: throw them and the system ships with quite a few senders of this method. Not to speak of our own code...

Joachim

Am Montag, 7. Januar 2013 14:43:13 UTC+1 schrieb [hidden email]:

This one is really bad.

In my Seaside Application I had plugged a subclass of WAHtmlError handler into my application in order to display an error page in case of exceptions instead of just crashing the application. This subclass did its job - but not every time. My packaged image would sometimes just crash and write a walkback log. Crashing is not in the scope of tolerable behaviors for a web server so I started digging a little. I found out my Error handler was simply ignored by Seaside in some cases. Without digging in the debugger I came to the conclusion this might be related to the instance-based exceptions in VAST, which Instantiations doesn't suggest to use any more, but still does in VAST, like in Object>>error:

So it turns out Seaside is not configured to catch ExAll or ExError in WAErrorHandler subclasses.

The fix, as far as I found out, is to change WAErrorHandler class>>exceptionSelector to:

exceptionSelector
^ super exceptionSelector, Error, Warning, ExError

Could someone at Instantiations please approve this fix and make sure it makes its way into Seaside asap? Would it be better to add ExAll rather than ExError? This would include Breakpoints, IIUC.
Please also think about whether WAErrorHandler or WAExceptionHandler would be the better place for it.

I temporarily solve this by adding it to my subclass of WAHtmlErrorHandler to avoid too much effort in migrating to newer Seaside base versions, but I wouldn't say that is a good solution. Catching errors in VAST's Seaside port should work exactly the way it does on other Smalltalks out of the box.

This is really an annoying (and dangerous) bug, and since Instance Based Exceptions are very VAST specific, this will probably never be integrated into Seaside base code. If there is a need to move this whole exceptionSelector thing into Grease ore some portability applications, please take the responsibility to coordinate this with the Seaside project.

BTW, while we're at it: is there some kind of schedule when Instantiations ships a version of VAST that completely works with Class based exceptions? I mean, a possible fix for the problem could also be to rewrite methods like Object>>#error: to use Class Based exceptions. That would sure be the cleanest fix for this bug (not taking into account the amount of existing legacy code at customers).

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/RwphnEQFz40J.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

jtuchel

Re: 8.5.2/Seaside: WAExceptionHandler misses instance-based exceptions

In reply to this post by jtuchel

Hi again,

so I've attached a tiny demo that registers WAHtmlExceptionHandler with a Seaside Application and renders two links. One of the links throws an instance based exception and the other one signals a class-based exception.

I would expect both to work the same way: show an error page instead of just popping up a debugger. Remember, a debugger popping up in development means an exiting image in production.

The demo app registers itself with Seaside when it's loaded. So after loading the application into an image with Seaside loaded, simply point your browser to localhost:8080, follow the 'HTML error handling problem demo" link and see what happens.

I've tried a few things now in WAHtmlExceptionHandler but had no success so far. How have others solved or worked around this issue?

Joachim

Am Montag, 7. Januar 2013 14:43:13 UTC+1 schrieb [hidden email]:

This one is really bad.

In my Seaside Application I had plugged a subclass of WAHtmlError handler into my application in order to display an error page in case of exceptions instead of just crashing the application. This subclass did its job - but not every time. My packaged image would sometimes just crash and write a walkback log. Crashing is not in the scope of tolerable behaviors for a web server so I started digging a little. I found out my Error handler was simply ignored by Seaside in some cases. Without digging in the debugger I came to the conclusion this might be related to the instance-based exceptions in VAST, which Instantiations doesn't suggest to use any more, but still does in VAST, like in Object>>error:

So it turns out Seaside is not configured to catch ExAll or ExError in WAErrorHandler subclasses.

The fix, as far as I found out, is to change WAErrorHandler class>>exceptionSelector to:

exceptionSelector
^ super exceptionSelector, Error, Warning, ExError

Could someone at Instantiations please approve this fix and make sure it makes its way into Seaside asap? Would it be better to add ExAll rather than ExError? This would include Breakpoints, IIUC.
Please also think about whether WAErrorHandler or WAExceptionHandler would be the better place for it.

I temporarily solve this by adding it to my subclass of WAHtmlErrorHandler to avoid too much effort in migrating to newer Seaside base versions, but I wouldn't say that is a good solution. Catching errors in VAST's Seaside port should work exactly the way it does on other Smalltalks out of the box.

This is really an annoying (and dangerous) bug, and since Instance Based Exceptions are very VAST specific, this will probably never be integrated into Seaside base code. If there is a need to move this whole exceptionSelector thing into Grease ore some portability applications, please take the responsibility to coordinate this with the Seaside project.

BTW, while we're at it: is there some kind of schedule when Instantiations ships a version of VAST that completely works with Class based exceptions? I mean, a possible fix for the problem could also be to rewrite methods like Object>>#error: to use Class Based exceptions. That would sure be the cleanest fix for this bug (not taking into account the amount of existing legacy code at customers).

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/t8mU9ITdjIAJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

HtmlErrorHandlingProblemDemo.dat.zip (7K) Download Attachment

jtuchel

Re: 8.5.2/Seaside: WAExceptionHandler misses instance-based exceptions

Hi again,

I had a day off from Smalltalk yesterday and just now find the time to llok into this a bit deeper.

The problem you see when trying my little demo app is that clicking on "Thorw an instance based exception" immediately brings up a debugger instead of showing an html page, like clicking in the class based link does.

Staring at the debugger, I can see why adding ExAll to WAHtmlErrorHandler class>>#exceptionSelector doesn't work. Internally, VAST converts all class based exceptions to instance based ones in ExceptionSet>>handle:do:, and because WAHtmlErrorHandler includes Error and Warning by default, and because Error is being converted to ExError in the above-mentioned method, adding ExAll or ExError doesn't actually add muchto the default behavior. Before my change, the converted collection included ExError and ExWarning, and now it includes ExAll in addition to that. My callback throws an ExError, so it shouild be caught by the initial ExceptionSet already.

Unfortunately, setting a Breakpoint or stepping deeper into the code (like in ExceptionEventCollection>>#when:do:) makes the image unresponsive until you hit the Break Button. So it seems I am unable to understand better what is wrong here.

So what can I do to make WAHtmlErrorHandler (or one of its superclasses) catch instance based exceptions?

Joachim

Am Montag, 7. Januar 2013 22:23:16 UTC+1 schrieb [hidden email]:

Hi again,

so I've attached a tiny demo that registers WAHtmlExceptionHandler with a Seaside Application and renders two links. One of the links throws an instance based exception and the other one signals a class-based exception.

I would expect both to work the same way: show an error page instead of just popping up a debugger. Remember, a debugger popping up in development means an exiting image in production.

The demo app registers itself with Seaside when it's loaded. So after loading the application into an image with Seaside loaded, simply point your browser to localhost:8080, follow the 'HTML error handling problem demo" link and see what happens.

I've tried a few things now in WAHtmlExceptionHandler but had no success so far. How have others solved or worked around this issue?

Joachim

Am Montag, 7. Januar 2013 14:43:13 UTC+1 schrieb [hidden email]:
This one is really bad.

In my Seaside Application I had plugged a subclass of WAHtmlError handler into my application in order to display an error page in case of exceptions instead of just crashing the application. This subclass did its job - but not every time. My packaged image would sometimes just crash and write a walkback log. Crashing is not in the scope of tolerable behaviors for a web server so I started digging a little. I found out my Error handler was simply ignored by Seaside in some cases. Without digging in the debugger I came to the conclusion this might be related to the instance-based exceptions in VAST, which Instantiations doesn't suggest to use any more, but still does in VAST, like in Object>>error:

So it turns out Seaside is not configured to catch ExAll or ExError in WAErrorHandler subclasses.

The fix, as far as I found out, is to change WAErrorHandler class>>exceptionSelector to:

exceptionSelector
^ super exceptionSelector, Error, Warning, ExError

Could someone at Instantiations please approve this fix and make sure it makes its way into Seaside asap? Would it be better to add ExAll rather than ExError? This would include Breakpoints, IIUC.
Please also think about whether WAErrorHandler or WAExceptionHandler would be the better place for it.

I temporarily solve this by adding it to my subclass of WAHtmlErrorHandler to avoid too much effort in migrating to newer Seaside base versions, but I wouldn't say that is a good solution. Catching errors in VAST's Seaside port should work exactly the way it does on other Smalltalks out of the box.

This is really an annoying (and dangerous) bug, and since Instance Based Exceptions are very VAST specific, this will probably never be integrated into Seaside base code. If there is a need to move this whole exceptionSelector thing into Grease ore some portability applications, please take the responsibility to coordinate this with the Seaside project.

BTW, while we're at it: is there some kind of schedule when Instantiations ships a version of VAST that completely works with Class based exceptions? I mean, a possible fix for the problem could also be to rewrite methods like Object>>#error: to use Class Based exceptions. That would sure be the cleanest fix for this bug (not taking into account the amount of existing legacy code at customers).

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/SI6aoJ04VIQJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

John O'Keefe-3

Re: 8.5.2/Seaside: WAExceptionHandler misses instance-based exceptions

Joachim -

The instance-based exception ExAll is equivilent to the class-based exception Exception. There are several instance-based exceptions that decend from ExAll (inspect ExceptionalEvent allInstances which should give you an array of about 80 instances if you have all features loaded -- then look for instances with a parent of ExAll), so they won't be caught unless you add either Exception or ExAll. Since ExHalt is a child of ExAll, setting a breakpoint when you are catching ExAll doesn't work too well.

Going back to an earlier post where you asked if we would ever replace all the instance-based exceptions with class-based exceptions, my answer is "I doubt it". There is simple too much code that would be broken (including the VM). Code that uses on:do: to catch exceptions should be able to handle both instance- and class-based exceptions; code that uses when:do: can only handle instance-based exceptions.

John

On Wednesday, January 9, 2013 3:32:33 AM UTC-5, [hidden email] wrote:

Hi again,

I had a day off from Smalltalk yesterday and just now find the time to llok into this a bit deeper.

The problem you see when trying my little demo app is that clicking on "Thorw an instance based exception" immediately brings up a debugger instead of showing an html page, like clicking in the class based link does.

Staring at the debugger, I can see why adding ExAll to WAHtmlErrorHandler class>>#exceptionSelector doesn't work. Internally, VAST converts all class based exceptions to instance based ones in ExceptionSet>>handle:do:, and because WAHtmlErrorHandler includes Error and Warning by default, and because Error is being converted to ExError in the above-mentioned method, adding ExAll or ExError doesn't actually add muchto the default behavior. Before my change, the converted collection included ExError and ExWarning, and now it includes ExAll in addition to that. My callback throws an ExError, so it shouild be caught by the initial ExceptionSet already.

Unfortunately, setting a Breakpoint or stepping deeper into the code (like in ExceptionEventCollection>>#when:do:) makes the image unresponsive until you hit the Break Button. So it seems I am unable to understand better what is wrong here.

So what can I do to make WAHtmlErrorHandler (or one of its superclasses) catch instance based exceptions?

Joachim

Am Montag, 7. Januar 2013 22:23:16 UTC+1 schrieb [hidden email]:

Hi again,

so I've attached a tiny demo that registers WAHtmlExceptionHandler with a Seaside Application and renders two links. One of the links throws an instance based exception and the other one signals a class-based exception.

I would expect both to work the same way: show an error page instead of just popping up a debugger. Remember, a debugger popping up in development means an exiting image in production.

The demo app registers itself with Seaside when it's loaded. So after loading the application into an image with Seaside loaded, simply point your browser to localhost:8080, follow the 'HTML error handling problem demo" link and see what happens.

I've tried a few things now in WAHtmlExceptionHandler but had no success so far. How have others solved or worked around this issue?

Joachim

Am Montag, 7. Januar 2013 14:43:13 UTC+1 schrieb [hidden email]:
This one is really bad.

In my Seaside Application I had plugged a subclass of WAHtmlError handler into my application in order to display an error page in case of exceptions instead of just crashing the application. This subclass did its job - but not every time. My packaged image would sometimes just crash and write a walkback log. Crashing is not in the scope of tolerable behaviors for a web server so I started digging a little. I found out my Error handler was simply ignored by Seaside in some cases. Without digging in the debugger I came to the conclusion this might be related to the instance-based exceptions in VAST, which Instantiations doesn't suggest to use any more, but still does in VAST, like in Object>>error:

So it turns out Seaside is not configured to catch ExAll or ExError in WAErrorHandler subclasses.

The fix, as far as I found out, is to change WAErrorHandler class>>exceptionSelector to:

exceptionSelector
^ super exceptionSelector, Error, Warning, ExError

Could someone at Instantiations please approve this fix and make sure it makes its way into Seaside asap? Would it be better to add ExAll rather than ExError? This would include Breakpoints, IIUC.
Please also think about whether WAErrorHandler or WAExceptionHandler would be the better place for it.

I temporarily solve this by adding it to my subclass of WAHtmlErrorHandler to avoid too much effort in migrating to newer Seaside base versions, but I wouldn't say that is a good solution. Catching errors in VAST's Seaside port should work exactly the way it does on other Smalltalks out of the box.

This is really an annoying (and dangerous) bug, and since Instance Based Exceptions are very VAST specific, this will probably never be integrated into Seaside base code. If there is a need to move this whole exceptionSelector thing into Grease ore some portability applications, please take the responsibility to coordinate this with the Seaside project.

BTW, while we're at it: is there some kind of schedule when Instantiations ships a version of VAST that completely works with Class based exceptions? I mean, a possible fix for the problem could also be to rewrite methods like Object>>#error: to use Class Based exceptions. That would sure be the cleanest fix for this bug (not taking into account the amount of existing legacy code at customers).

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/yUQdfyPLjkkJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

jtuchel

Re: 8.5.2/Seaside: WAExceptionHandler misses instance-based exceptions

Hi John,

thank you for answering.

I tried both ExAll and ExError in WAErrorHandler class>>exceptionSelector, and both don't get caught, but I cannot see for what reason.
In my demo application, I signal an ExError as an example for an instance based exception, so both ExAll and ExError should catch it, right? But both don't. I guess the problem here is not that I try to catch the wrong exceptions, but some other bug that I can't find...

But at least I now understand why my breakpoint made the image "sleep".

Joachim

Am Mittwoch, 9. Januar 2013 16:31:08 UTC+1 schrieb John O'Keefe:

Joachim -

The instance-based exception ExAll is equivilent to the class-based exception Exception. There are several instance-based exceptions that decend from ExAll (inspect ExceptionalEvent allInstances which should give you an array of about 80 instances if you have all features loaded -- then look for instances with a parent of ExAll), so they won't be caught unless you add either Exception or ExAll. Since ExHalt is a child of ExAll, setting a breakpoint when you are catching ExAll doesn't work too well.

Going back to an earlier post where you asked if we would ever replace all the instance-based exceptions with class-based exceptions, my answer is "I doubt it". There is simple too much code that would be broken (including the VM). Code that uses on:do: to catch exceptions should be able to handle both instance- and class-based exceptions; code that uses when:do: can only handle instance-based exceptions.

John

On Wednesday, January 9, 2013 3:32:33 AM UTC-5, [hidden email] wrote:
Hi again,

I had a day off from Smalltalk yesterday and just now find the time to llok into this a bit deeper.

The problem you see when trying my little demo app is that clicking on "Thorw an instance based exception" immediately brings up a debugger instead of showing an html page, like clicking in the class based link does.

Staring at the debugger, I can see why adding ExAll to WAHtmlErrorHandler class>>#exceptionSelector doesn't work. Internally, VAST converts all class based exceptions to instance based ones in ExceptionSet>>handle:do:, and because WAHtmlErrorHandler includes Error and Warning by default, and because Error is being converted to ExError in the above-mentioned method, adding ExAll or ExError doesn't actually add muchto the default behavior. Before my change, the converted collection included ExError and ExWarning, and now it includes ExAll in addition to that. My callback throws an ExError, so it shouild be caught by the initial ExceptionSet already.

Unfortunately, setting a Breakpoint or stepping deeper into the code (like in ExceptionEventCollection>>#when:do:) makes the image unresponsive until you hit the Break Button. So it seems I am unable to understand better what is wrong here.

So what can I do to make WAHtmlErrorHandler (or one of its superclasses) catch instance based exceptions?

Joachim

Am Montag, 7. Januar 2013 22:23:16 UTC+1 schrieb [hidden email]:

Hi again,

so I've attached a tiny demo that registers WAHtmlExceptionHandler with a Seaside Application and renders two links. One of the links throws an instance based exception and the other one signals a class-based exception.

I would expect both to work the same way: show an error page instead of just popping up a debugger. Remember, a debugger popping up in development means an exiting image in production.

The demo app registers itself with Seaside when it's loaded. So after loading the application into an image with Seaside loaded, simply point your browser to localhost:8080, follow the 'HTML error handling problem demo" link and see what happens.

I've tried a few things now in WAHtmlExceptionHandler but had no success so far. How have others solved or worked around this issue?

Joachim

Am Montag, 7. Januar 2013 14:43:13 UTC+1 schrieb [hidden email]:
This one is really bad.

In my Seaside Application I had plugged a subclass of WAHtmlError handler into my application in order to display an error page in case of exceptions instead of just crashing the application. This subclass did its job - but not every time. My packaged image would sometimes just crash and write a walkback log. Crashing is not in the scope of tolerable behaviors for a web server so I started digging a little. I found out my Error handler was simply ignored by Seaside in some cases. Without digging in the debugger I came to the conclusion this might be related to the instance-based exceptions in VAST, which Instantiations doesn't suggest to use any more, but still does in VAST, like in Object>>error:

So it turns out Seaside is not configured to catch ExAll or ExError in WAErrorHandler subclasses.

The fix, as far as I found out, is to change WAErrorHandler class>>exceptionSelector to:

exceptionSelector
^ super exceptionSelector, Error, Warning, ExError

Could someone at Instantiations please approve this fix and make sure it makes its way into Seaside asap? Would it be better to add ExAll rather than ExError? This would include Breakpoints, IIUC.
Please also think about whether WAErrorHandler or WAExceptionHandler would be the better place for it.

I temporarily solve this by adding it to my subclass of WAHtmlErrorHandler to avoid too much effort in migrating to newer Seaside base versions, but I wouldn't say that is a good solution. Catching errors in VAST's Seaside port should work exactly the way it does on other Smalltalks out of the box.

This is really an annoying (and dangerous) bug, and since Instance Based Exceptions are very VAST specific, this will probably never be integrated into Seaside base code. If there is a need to move this whole exceptionSelector thing into Grease ore some portability applications, please take the responsibility to coordinate this with the Seaside project.

BTW, while we're at it: is there some kind of schedule when Instantiations ships a version of VAST that completely works with Class based exceptions? I mean, a possible fix for the problem could also be to rewrite methods like Object>>#error: to use Class Based exceptions. That would sure be the cleanest fix for this bug (not taking into account the amount of existing legacy code at customers).

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/Jm7vpDK2QhcJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

jtuchel

Re: 8.5.2/Seaside: WAExceptionHandler misses instance-based exceptions

Hi again,

I finally found the place that's wrong. WAErrorHandler is only prepared for class based exceptions. Here's what I've changed it to in my image (no beauty contest to be won by my code here):

handleException: anException

(Error handles: anException) ifTrue: [^self handleError: anException].

(Warning handles: anException) ifTrue: [^self handleWarning: anException].

(anException isKindOf: Signal)

ifTrue: [(ExError handles: anException exception) ifTrue: [^self handleError: anException]].

^super handleException: anException

Joachim

Am Mittwoch, 9. Januar 2013 20:23:45 UTC+1 schrieb [hidden email]:

Hi John,

thank you for answering.

I tried both ExAll and ExError in WAErrorHandler class>>exceptionSelector, and both don't get caught, but I cannot see for what reason.
In my demo application, I signal an ExError as an example for an instance based exception, so both ExAll and ExError should catch it, right? But both don't. I guess the problem here is not that I try to catch the wrong exceptions, but some other bug that I can't find...

But at least I now understand why my breakpoint made the image "sleep".

Joachim

Am Mittwoch, 9. Januar 2013 16:31:08 UTC+1 schrieb John O'Keefe:
Joachim -

The instance-based exception ExAll is equivilent to the class-based exception Exception. There are several instance-based exceptions that decend from ExAll (inspect ExceptionalEvent allInstances which should give you an array of about 80 instances if you have all features loaded -- then look for instances with a parent of ExAll), so they won't be caught unless you add either Exception or ExAll. Since ExHalt is a child of ExAll, setting a breakpoint when you are catching ExAll doesn't work too well.

Going back to an earlier post where you asked if we would ever replace all the instance-based exceptions with class-based exceptions, my answer is "I doubt it". There is simple too much code that would be broken (including the VM). Code that uses on:do: to catch exceptions should be able to handle both instance- and class-based exceptions; code that uses when:do: can only handle instance-based exceptions.

John

On Wednesday, January 9, 2013 3:32:33 AM UTC-5, [hidden email] wrote:
Hi again,

I had a day off from Smalltalk yesterday and just now find the time to llok into this a bit deeper.

The problem you see when trying my little demo app is that clicking on "Thorw an instance based exception" immediately brings up a debugger instead of showing an html page, like clicking in the class based link does.

Staring at the debugger, I can see why adding ExAll to WAHtmlErrorHandler class>>#exceptionSelector doesn't work. Internally, VAST converts all class based exceptions to instance based ones in ExceptionSet>>handle:do:, and because WAHtmlErrorHandler includes Error and Warning by default, and because Error is being converted to ExError in the above-mentioned method, adding ExAll or ExError doesn't actually add muchto the default behavior. Before my change, the converted collection included ExError and ExWarning, and now it includes ExAll in addition to that. My callback throws an ExError, so it shouild be caught by the initial ExceptionSet already.

Unfortunately, setting a Breakpoint or stepping deeper into the code (like in ExceptionEventCollection>>#when:do:) makes the image unresponsive until you hit the Break Button. So it seems I am unable to understand better what is wrong here.

So what can I do to make WAHtmlErrorHandler (or one of its superclasses) catch instance based exceptions?

Joachim

Am Montag, 7. Januar 2013 22:23:16 UTC+1 schrieb [hidden email]:

Hi again,

so I've attached a tiny demo that registers WAHtmlExceptionHandler with a Seaside Application and renders two links. One of the links throws an instance based exception and the other one signals a class-based exception.

I would expect both to work the same way: show an error page instead of just popping up a debugger. Remember, a debugger popping up in development means an exiting image in production.

The demo app registers itself with Seaside when it's loaded. So after loading the application into an image with Seaside loaded, simply point your browser to localhost:8080, follow the 'HTML error handling problem demo" link and see what happens.

I've tried a few things now in WAHtmlExceptionHandler but had no success so far. How have others solved or worked around this issue?

Joachim

Am Montag, 7. Januar 2013 14:43:13 UTC+1 schrieb [hidden email]:
This one is really bad.

In my Seaside Application I had plugged a subclass of WAHtmlError handler into my application in order to display an error page in case of exceptions instead of just crashing the application. This subclass did its job - but not every time. My packaged image would sometimes just crash and write a walkback log. Crashing is not in the scope of tolerable behaviors for a web server so I started digging a little. I found out my Error handler was simply ignored by Seaside in some cases. Without digging in the debugger I came to the conclusion this might be related to the instance-based exceptions in VAST, which Instantiations doesn't suggest to use any more, but still does in VAST, like in Object>>error:

So it turns out Seaside is not configured to catch ExAll or ExError in WAErrorHandler subclasses.

The fix, as far as I found out, is to change WAErrorHandler class>>exceptionSelector to:

exceptionSelector
^ super exceptionSelector, Error, Warning, ExError

Could someone at Instantiations please approve this fix and make sure it makes its way into Seaside asap? Would it be better to add ExAll rather than ExError? This would include Breakpoints, IIUC.
Please also think about whether WAErrorHandler or WAExceptionHandler would be the better place for it.

I temporarily solve this by adding it to my subclass of WAHtmlErrorHandler to avoid too much effort in migrating to newer Seaside base versions, but I wouldn't say that is a good solution. Catching errors in VAST's Seaside port should work exactly the way it does on other Smalltalks out of the box.

This is really an annoying (and dangerous) bug, and since Instance Based Exceptions are very VAST specific, this will probably never be integrated into Seaside base code. If there is a need to move this whole exceptionSelector thing into Grease ore some portability applications, please take the responsibility to coordinate this with the Seaside project.

BTW, while we're at it: is there some kind of schedule when Instantiations ships a version of VAST that completely works with Class based exceptions? I mean, a possible fix for the problem could also be to rewrite methods like Object>>#error: to use Class Based exceptions. That would sure be the cleanest fix for this bug (not taking into account the amount of existing legacy code at customers).

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/62sBGQpyjq0J.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

John O'Keefe

Re: 8.5.2/Seaside: WAExceptionHandler misses instance-based exceptions

In reply to this post by jtuchel

The problem was actually in Exception class>>#handles: since it did not account for instance-based exceptions. The replacement method is attached.
case50307.st