expected exception behavior WAWalkbackErrorHandler not portable (and not ANSI compliant)

[GoogleCodeExporter]

Hi All,
   Here's something interesting that came up with respect to Seaside in VisualWorks. The basic symptom is that if you have an error in a component, in Squeak you would get a debugger in the web browser. In VisualWorks you would get a debugger coming up in the image, and it would be on a somewhat different stack, the actual error being an unhandled render notification. The root of this seems to be a difference in exception behaviour between Squeak/Pharo and VisualWorks.

   The difference is a bit tricky to explain, so I'll also put in a code fragment that illustrates. Basically, if an exception is caught, and the handler block signals another exception, where does that exception begin looking for handlers. In VisualWorks, and in VisualAge, which are the only two I tested, it starts at the place it was raised. In Squeak and Pharo it appears that it starts at the, um, bottom again. This manifests in Seaside as
...
  Generic Error handler
    ...
      WARenderNotificationHandler
        ...
          error

So the error is raised, is caught by the generic error handler, and as a result 
it wants to display a debugger. Displaying a debugger wants to render a page, 
so it throws a WARenderNotification. But the only handler for that is further 
down in the stack, and so it's not caught. In Squeak and Pharo it appears that 
throwing that exception behaves more like resignalAs: behaves in VisualWorks 
(the resignalAs: method is a not yet implemented in VisualAge). Reading the 
ANSI specification, it's extraordinarily fuzzy about it, but I *think* it's 
describing the VisualWorks behaviour when it says 
If a matching handler is found, the exception action of the handler is 
evaluated in the exception environment that was current when the handler was 
created and the state of the current exception environment is preserved as the 
signaling environment.


We think we can hack our way around that by specially coding Grease 
notifications to behave differently from other exceptions, but it's certainly 
not pretty, and it would be good if there was a cleaner way of dealing with it.

To more concretely illustrate what I'm talking about, consider defining an 
exception class ExceptionOne. Then define a class First with a method 
startHere
    "First new startHere"
    [Second new doStuff] on: Error do: [:ex | Transcript cr; show: 'exception in startHere'. ExceptionOne signal].

And a class Second, with
doStuff
    [self doMoreStuff] on: ExceptionOne do: [:ex | Transcript cr; show: 'Exception in doStuff'].

and 

doMoreStuff
    Transcript cr; show: 'Doing more stuff...'.
    3 / 0.

In VisualWorks and VisualAge that results in an uncaught ExceptionOne and a 
debugger. In Pharo 1.1 one-click it just prints 3 things to the Transcript, the 
same behaviour I'd get in VisualWorks if I change the startHere method to do 
"ex resiganlAs: ExceptionOne new"


-- 
Alan Knight [|], Engineering Manager, Cincom Smalltalk
knight@acm.org
aknight@cincom.com
http://www.cincom.com/smalltalk

Original issue reported on code.google.com by philippe...@gmail.com on 28 Jan 2011 at 8:19

[GoogleCodeExporter]

The only way to fix this is moving the error handler inside the render loop, 
probably inside the session like it was in Seaside 2.8. We can even loop up the 
same exception handler like the exception filter.

Original comment by philippe...@gmail.com on 28 Jan 2011 at 8:23

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

A hacky "fix" that works in VAST is

WARenderLoopContinuation >> #withNotificationHandlerDo: aBlock
       ^ [ (self exceptionFilter  exceptionHandler context: self requestContext)
               handleExceptionsDuring:  aBlock ]
               on: WARenderNotification do: [ :n | ]


WARenderLoopContinuation >> #exceptionFilter
       ^ self application filters detect: [ :each | each isExceptionFilter ] ifNone: [ nil ]

Original comment by philippe...@gmail.com on 28 Aug 2011 at 10:50

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Name: Seaside-Core-pmm.756
Author: pmm
Time: 29 August 2011, 4:37:01 pm
UUID: 6ce06a2e-c78a-4992-a671-33e10d7838e6
Ancestors: Seaside-Core-pmm.755

- Issue 636:    expected exception behavior WAWalkbackErrorHandler not portable 
(and not ANSI compliant)
- nest exception handlers

Name: Seaside-RenderLoop-pmm.81
Author: pmm
Time: 29 August 2011, 4:34:44 pm
UUID: f2b2f214-b5fb-4700-9709-5aba36060b2d
Ancestors: Seaside-RenderLoop-pmm.80

- Issue 636:    expected exception behavior WAWalkbackErrorHandler not portable 
(and not ANSI compliant)
- nest exception handlers

Name: Seaside-Tests-RenderLoop-pmm.12
Author: pmm
Time: 29 August 2011, 4:38:38 pm
UUID: 8f3d5d6f-34fc-4f72-b767-7313cb2dbb01
Ancestors: Seaside-Tests-RenderLoop-lr.11

- Issue 636:    expected exception behavior WAWalkbackErrorHandler not portable 
(and not ANSI compliant)
- nest exception handlers

Original comment by philippe...@gmail.com on 29 Aug 2011 at 3:39

• Changed state: Fixed
• Added labels: Version-Seaside3.1
• Removed labels: ****