Error handling in Flapjax

11 views
Skip to first unread message

noel...@gmail.com

unread,
Jan 2, 2007, 7:30:37 AM1/2/07
to Flapjax
What's the best idiom for error handling in Flapjax? In standard
Javascript if a function wants to signal an error to its caller it
could return a specific value or throw an exception. In Flapjax we
communicate via asynchronous events, not function calls, so we have
receiver and sender instead of caller and callee, and extra steps are
necessary to synchronise. If the receiver throws an exception the
sender won't actually be in a situation to catch that exception (given
what I assume about the implementation). So presumably some handshake
is necessary. For example, the sender might pass an continuation event
to the receiver. The receiver could then send true on the continuation
event to indicate success, or false to indicate failure. However,
manual CPS is generally considered a sign of a kludgy implementation.
Synchronous events would solve this problem. In the tradition of
answering my own questions, I think I can build something like a
synchronous event using if_e (it won't be truly synchronous, but it
will solve the problem). Anyone else have any comments to make on this
issue?

If your head is spinning, here's an example:

Let's say I have two components. The data store (aka model) stores
some data, say the name of a person. The UI (aka view/controller) is a
text field that allows the user to enter data. The UI communicates via
the data store via an event, say updateE. The UI send the contents of
the text field to updateE when the user presses Enter in the text
field. The data store validates this data against a list of allowed
names. If the name is invalid it needs to tell the UI to prompt the
user again. This is easy to handle if the UI and data store are
statically known. If so the data store can send an event to the UI.
It is not so easy if, say, the UI component exists inside other
'container' components, or UI components are dynamically generated.
Some abstraction is necessary to solve these problems.

Thanks,
Noel

Leo Meyerovich

unread,
Jan 4, 2007, 11:39:07 PM1/4/07
to fla...@googlegroups.com
Hiya Noel,

> What's the best idiom for error handling in Flapjax?

In the server library, we started with the simplest approach we could
think of: explicit separate exception channels as part of returned
objects. Best practices are still forming.

> So presumably some handshake is necessary... However,


> manual CPS is generally considered a sign of a kludgy implementation.

Yep. My basic approach so far is to either pass all necessary data in
the exception stream or to make handshakes.

> I think I can build something like a
> synchronous event using if_e (it won't be truly synchronous, but it
> will solve the problem). Anyone else have any comments to make on this
> issue?

We talked about lightweight and language level approaches, but best
practices still seem unclear. I had talked about this with Guillaume
and Greg, and they had some ideas here for FrTime that did not
entirely pan out. I haven't read much about this in the literature,
but have a suspicion something might exist in some of the older
languages from the early 90s that have lingered.

We actually do append path information in the current approach, so an
event receiver can plausibly bubble up an error to its sender (and
possibly beyond). "propagatePulse" would be the place to start looking
at implementing this. A quick implementation would be to run
propagation in a try/catch block, and upon a catch, walk up the call
('pulse') path until some sort of exception handling event stream (a
subtype of nodes, say trycatch_e) is found.

I think there is often a clear causal link even in the asynchronous
case, such as when a delay is used. However, as always, state gets
murky, in our case with calls like collect. I haven't done enough
error handling in my own application code to discern what is desired
generally vs in specific circumstances.

Keep on keepin' on,

- Leo

Reply all
Reply to author
Forward
0 new messages