[Seaside] VW WAWalkbackErrorHandler in 3.0

Bob N. bobn at rogers.com
Fri Nov 19 12:35:51 UTC 2010


Evidently, that's just the way it is (we opened a case with Cincom, 424170).
 Exception handling is handled well by WebVelocity but that code will not be
ported to their Seaside implementation.  Unless I'm missing something,
subclassing WAExceptionHandler in VW is of little use since
WAUnhandledNotificationError
will be raised when the exception handler is called, and that opens a
debugger on the server.

It's easy to see the difference between Pharo and VW using something
like...

renderContentOn: html
    html form: [
          html button
              callback: [self error: 'This is only a test'];
              with: 'Press for error']

In VW, this opens a debugger on the server.  If you then press 'run' you'll
see a stack trace on the browser.
In Pharo, this renders a stack trace on the browser, and if you press
'debug' it opens a debugger on the server.

I'd love to know how others have worked around this.
Thanks,
Bob

<...>

It sounds like you are not in a render phase when hitting your error,
> though, since a WARenderNotification is being signaled. Signaling that
> notification is completely normal and happens at the end of more or
> less any action phase to indicate that a new render pass should begin.
> This is normally caught by
> WARenderLoopContinuation>>withNotificationHandlerDo: so the question
> is, why is the VW implementation not doing so?
>
> Michael may be able to shed some light or maybe you can determine more
> by looking further up your context chain...
>
> Julian
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20101119/59ed784f/attachment.htm


More information about the seaside mailing list