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
> 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