Hi,

A weirdness we had in our system was that the accessor called by a Magritte description raised an Error. This code is called in a callback of a button:

[ 
aComponent
call:
(MatchInvestmentPage new
instruction: self;
yourself).
aComponent reset ]
on: Error
do: [ :err | 
aComponent inform: err messageText.
aComponent answer ]

It tries to handle the error raised by "aComponent reset". The MatchInvestmentPage component changes the state of the model of aComponent (a magritte container component). The "aComponent reset" causes a magritte MADescription (displaying a fairly simple amount field) to call an accessor on the model, which raises the error. 

We now removed this error handler and check for the error condition elsewhere.

A broader question here is whether magritte descriptions should handle exceptions when reading from the model (Object >> readUsing: which calls #read: on). 

Our understanding is that reading via accessors (MAAccessor descendants) should not handle exceptions and a fallback (outer) handler should handle it, because this is really unexpected. Is this right? Does anyone know what the best way is to handle this situation?

Does it make sense to handle exceptions at the description level and display a message to the user (on the field itself)? Not sure that it does, but perhaps someone have better ideas here.

Thanks
Otto

PS. Does anyone have suggestions on nicer dialogs (the inform: call here) that perhaps uses JQuery or another mechanism?



On Wed, May 21, 2014 at 10:45 AM, Otto Behrens <otto@finworks.biz> wrote:
Hi,

Pardon the delay on the response here. We decided to simplify the flow of screens here to avoid the problem, in the light of a possibly complex way that we're implementing the requirement and a pressing client.

But we'd like to explore this a bit more to see if we can find this because it may be a problem elsewhere in our system or for someone else.

Firstly, we are using https://github.com/glassdb/Seaside30. The comment says Seaside 3.0.7.1. I don't know how to figure out what version of seaside this is besides trusting the comment. Looking at logs when loading from scratch does not tell me much. How will I go about figuring out the version that we've got loaded? From Johan's recent mail, I take it that https://github.com/glassdb/Seaside31 could be good to upgrade to.

To get back to the problem, I think the continuation was created with

Scriptaculous >> lightbox: aComponent
^ self wait: [ :cc | 
self 
show: aComponent
onAnswer: cc
delegation: (SULightbox new
delegate: aComponent;
yourself).
WARenderNotification signal ]

Yes, we still have some Scriptaculous bits to get rid of, so if this is the problem, the time is now.

What do you think? Is this it?

Thanks
Otto


On Tue, May 20, 2014 at 3:05 AM, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
Otto,

Another possibility ... although I don't know if this kind of thing would be possible but here goes nothing ...

If the callback that we're looking at with the broken stack was created during WADispatchCallback>>evaluateWithArgument: or WAMultiSelectTag>>triggerCallback and inform: answer was run in  WACallbackRegistry>>handle:, then the call back would have been created with one less frame on the stack (no do: frame) ...  and that would provide us with a nice off by one error ...

some logging in the methods WADispatchCallback>>evaluateWithArgument: and WAMultiSelectTag>>triggerCallback, where you record the oop of theWACallback instance  and  logging in WACallbackRegistry>>handle: recording the oops of WACallbacks run should rule this hare-brained idea out or rule it right into play:) ...

Dale


On Mon, May 19, 2014 at 5:41 PM, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
Otto,

I haven't been able to reproduce the bad error yet and I think that the corruption is being caused by the previous callback in the set ... the stack is corrupt at the point you try to create the continuation for the inform: in the validation block ...

setting breakpoints in the WACallback>>evaluateWithFieldValues: will catch the first callback in this sequence .. check to see if the stack looks corrupt in the first call, then continue and see if the stack looks corrupt before executing the code for the second callback ... if we can isolate the transition from good stack to bad stack, we'll be on our way to a solution...

I'm a bit suspicious of Magritte in the mix and the#reset message ... if the structure of objects have been changed between the time the continuation is created and the time it gets used, there might be trouble ... but I'm only grasping at straws at this point in time ... BTW, what version of Seaside and Magritte are you using?

If Pieter's case is simpler, we might be able to figure it out easier ... I'd like to see the two addForm: methods:) Just in case something jumps out at me...

Dale




On Mon, May 19, 2014 at 2:48 PM, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
Otto,

Given an instance of WACallback, you can determine the source code of the method where the callback is defined by looking at the `block` instance variable og a WACallBack instance ... then in 3.1:

  block _method sourceString.              "source"
  block _method inClass                        "class"
  block _method _lineDeltaForBlock    "line number in source (ignoring selector)"

This can be done from a debugger (topaz) when error occurs ... navigate up the stack to the WACallback>>evaluateWithFieldValues: frame... get the oop of the _method (use `display oops`) and then sued the `send` command to send the three different messages:

  send @34379893 sourceString

... still digging ...

Dale



On Mon, May 19, 2014 at 10:55 AM, Otto Behrens <otto@finworks.biz> wrote:
Thank you, Dale. I'm finally at home :)


On Monday, May 19, 2014, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
Otto,

Thanks!

I'm finally in the office ) and will spend some time today getting myself grounded in continuations again ... then I should have a better idea how to proceed ...

Dale


On Mon, May 19, 2014 at 9:47 AM, Otto Behrens <otto@finworks.biz> wrote:
> perhaps capturing the stack at the point the continue is created will give
> us clues ...

Attached are some stacks that I hacked in by calling the following
method where we create them:

WAPartialContinuation >> printStack
| stream |
stream := GsFile openWriteOnServer: '/tmp/stack_', self asOop printString.
[ stream nextPutAll: partial printString ] ensure: [ stream close ]

It does not tell me much at the moment. But perhaps you can see
something. Or perhaps you have a better printing method that I can
call?

Thanks
Otto