Re: ACTION-1868 - Bruchez to summarize problems with error handling and three options for variable type handling

Hi Erik,

I think that the specified behaviour is overall quite consistent and makes some kind of recovery possible. I don't know if the recovery is powerful enough, but you can at least prevent a 'crash' of the form. I think that it will be hard to get the form in a consistent state after the error though...

I have one small remark. I would have expected an empty sequence for a model switch to a non-existing model (just like other error conditions fall back to an 'empty' evaluation context) instead of the current specified behaviour (keeping the current evaluation context).

Kind regards,

Nick Van den Bleeken
R&D Manager

Phone: +32 3 425 41 02
Office fax: +32 3 821 01 71
nick.van.den.bleeken@inventivegroup.com<mailto:nick.van.den.bleeken@inventivegroup.com>
www.inventivedesigners.com


[cid:image001.png@01CBF2F8.1DA19110][cid:image002.png@01CBF2F8.1DA19110][cid:image003.png@01CBF2F8.1DA19110]

On 02 Oct 2013, at 00:05, Erik Bruchez <erik@bruchez.org<mailto:erik@bruchez.org>> wrote:

All,

## Introduction

This action item dates back to February 2012 and was revived in our last call:

http://lists.w3.org/Archives/Public/public-forms/2012Feb/att-0027/2012-02-15.html

## Error handling with XForms 1.1

First, let's summarize the error handling issues in XForms.

A number of things can go wrong in an XForms page. For most
attributes, we define a default behavior. For example: "If the src
attribute is omitted, then…". However errors that happen in XPath
expressions are handled with the dispatching of two events:

- `xforms-binding-exception` when on bindings (`ref`)
- `xforms-compute-exception` when somewhere else

Note that `xforms-compute-exception` is also dispatched when there are
circular dependencies in the model, and that
`xforms-compute-exception` is used more generally to indicate issues
with bindings, even when no XPath expression is involved.

This is what XForms 1.1 says:

"At the time of evaluation, an XPath expression must be syntactically correct. In addition, the namespaces the expression references must be in scope and the functions and variables it references must be defined. If any of these conditions is not satisfied, an exception (4.5.2 The xforms-compute-exception Event) is raised, except for binding expressions, which produce a different exception (4.5.1 The xforms-binding-exception Event)."

Both these events are not cancelable. This means that the default
action always runs, and thus always halts XForms processing
completely. In short, it is never possible to recover from an XPath
error with XForms 1.1 (or 2.0 in its present state).

This is a problem, because for author have no control over what to do
in case such errors happen. In particular there is a chance that data
loss will occur due to a typo in an XPath expression or some
unexpected dynamic condition.

Better error handling can help alleviate that (for example, by asking
the user to try to save a draft of the data to recover it later).
Also, all systems I know have at least one mechanism to recover from
errors.

## What we do in our implementation

Since about two years agao, our implementation specifies a different
behavior, documented here:

http://wiki.orbeon.com/forms/welcome/xforms-error-handling

and in this blog post:

http://blog.orbeon.com/2011/11/more-resilient-error-handling-in-xforms.html

After about two years of experience, we are quite happy with the solution.

## The new error handling philosophy in short

The XForms processor:

- attempts to recover from errors occurring with XPath expressions,
bindings, and actions
- but also dispatches recoverable error events in these cases

The default action of the recoverable errors, for backward
compatibility, could still be to halt processing. But we could decide
otherwise.

Because the error events are cancelable, it is always possible to
recover when desired.

(Although there is no guarantee of being able to recover *meaningfully*.)

The two exception XForms 1.1 events are no longer dispatched:

- `xforms-binding-exception`
- `xforms-compute-exception`

## Recovery outside of actions

The XForms processor, when encountering an error with an XPath
expression (static or dynamic, in XPath 2 terms), or an error with a
binding, determines a recovery value for the expression.

Here are all the cases that we have identified:

1. For control bindings, model bindings, values, variables
   - Upon XPath errors, a default value is chosen:
       - the empty sequence for bindings and variable values
       - the empty string for string values
       - `xforms-xpath-error` is dispatched
   - Upon binding errors with the `bind` attribute
       - the binding resolves to the empty sequence
       - `xforms-binding-error` is dispatched
   - Upon binding errors with the `model` attribute
       - the model doesn't change, as if the model attribute was missing
       - `xforms-binding-error` is dispatched
2. For XPath MIP values
   - Upon XPath errors for `calculate`
       - the destination value is set to blank
       - `xforms-xpath-error` is dispatched
   - Upon XPath errors for other MIPs
       - the MIP is not modified, as if the attribute specifying the
property was missing
       - `xforms-xpath-error` is dispatched
   - Upon binding errors with complex or readonly content (`calculate` only)
       - the instance value is not modified
       - `xforms-binding-error` is dispatched to the model
3. For the submission `instance` attribute
   - Upon incorrect instance id
       - `xforms-submit-error` is dispatched (as in the case of a
target error with the `targetref` attribute)
   - Upon binding errors with complex or readonly content
       - `xforms-submit-error` is dispatched

## Recovery within actions

- Any error taking place during action processing stops the outermost
action handler, including:
   - XPath errors
   - binding errors with the `bind` or `model` attribute
   - binding errors with complex or readonly content
   - missing attributes or unsupported attribute values on action elements
- `xforms-action-error` event is dispatched to the observer of the action
   - this includes: controls, `model`, `instance`, and `submission`
- NOTE: Some actions silently ignore some error conditions, including:
   - `<setvalue>` pointing to an empty sequence or to an atomic item
(such as a string) instead of a node
   - `<delete>` with an empty sequence or an empty overridden context
   - `<insert>` with an empty or non-element insert context, an empty
overridden context, or an empty origin
   - actions with AVTs evaluating to the empty sequence
   - `<dispatch>`, `<send>`, `<setfocus>`, `<setindex>`, `<toggle>`
when the target element is not found

## User-friendliness

Implementations are allowed, if not encouraged, especially at
development time, to provide informative error messages to the
developer when errors occur, for example by logging to a console or
inspector.

## Summary of new events

The following events are added to XForms:

- `xforms-xpath-error` to indicate a general error with an XPath expression
- `xforms-binding-error` to indicate a general error with a binding
- `xforms-action-error` to indicate an error in an action handler

Feedback on this appreciated!

-Erik





________________________________

Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer