On Error

[Martin Stadler]

Hi!

I'm currently dealing with AMD robustness.

My first problem was a typo in a require statement. I was working in the Firebug console and requested a non-existing module. When I corrected the typo and entered the statement again, "ready" wouldn't fire. In the Dojo issue tracking I was told this is by the spec (http://bugs.dojotoolkit.org/ticket/13825) and I understand the argument but it is really annoying.

This leads me to a more general question: What if a dependency can't be correctly resolved in a reasonable time?

What is the AMD answer to this question? Does it provide any way to implement a fallback in error case like it is possible with XHR? Some kind of onError handler?

I have a case where I require a resource from an possibly unreliable server and if I can't handle errors the state of my whole application is broken.

Thanks,
Martin

[John Hann]

Hey Martin,

There is a disagreement amongst AMD implementors about this.  Some of us advocate a global amdLoader.onError handler.  Others advocate a local error handler.  Some examples of how this might work:

    // simple callback function for errors, "errback"

    require(["mymodule"], callback, errback);

    // CommonJS Promises/A (e.g. dojo/Deferred) or similar (such as jQuery.Deferred)

    require(["mymodule"]).then(callback, errback); 

    // promises, another way

    var dfd = new Deferred(); 

    require(["mymodule"], dfd.promise); 

    dfd.then(callback, errback);

Thoughts?

-- John

[James Burke]

On Thu, Sep 22, 2011 at 8:28 AM, John Hann <jo...@e-numera.com> wrote:
> Hey Martin,
> There is a disagreement amongst AMD implementors about this.  Some of us
> advocate a global amdLoader.onError handler.  Others advocate a local error
> handler.

[snip]
> Thoughts?

John is in the per-callback camp as I recall. I'm in the global error
handler camp (it is what requirejs uses). This is because:

It is difficult to ascertain a 404 or 500 error for a script because
of browser weaknesses. It is actually getting better, but IE is still
a stinking pile of pain. So the most you can hope for is a timeout,
not timely targeted errors.

I do not like having to mandate that AMD implementations need to trace
an bad module back to the require call (or calls) that may want to
know about it. That implies extra tracking in the loader to do this.

While on the surface it may make sense to add it to require(), I do
not think it makes sense to add to define() since the error handling
is specific to an app, not a defined module. I like that require and
define operate similarly, one just names a return value for use by
others (define).

So, for the define case, you need a global handler anyway, to handle
app-specific recovery.

I'm open to suggestions though, particularly if they are lightweight.
I appreciate that if an app does lots of dynamic require calls, it
would be useful to get targeted errors, but I'm skeptical that the
cost and reliability of doing so is worth it over just a global
handler.

James

[John Hann]

On Mon, Oct 3, 2011 at 11:37 PM, James Burke <jrb...@gmail.com> wrote:

John is in the per-callback camp as I recall.

:) #truth

 

It is difficult to ascertain a 404 or 500 error for a script because

of browser weaknesses. It is actually getting better, but IE is still
a stinking pile of pain. So the most you can hope for is a timeout,
not timely targeted errors.

This is not true.  Only non-AMD javascript files have this problem.  Since AMD files will execute at least one define() call in a loaded file, it's rather easy to determine if a module wasn't loaded.  Even in IE.  curl.js detects errors reliably already by looking for at least one define call.  

 

I do not like having to mandate that AMD implementations need to trace
an bad module back to the require call (or calls) that may want to
know about it. That implies extra tracking in the loader to do this.

Not entirely true. curl.js and the dojo loader (iiuc) have the necessary mechanics already.  Also, if I understand how loadrunner works, it's got the infrastructure to track errors as well.  I don't know how any other loaders work, so I can't speak about them.

curl.js extends this functionality to its plugins, too.  curl.js detects if the loader supports the error path by sniffing for a promise-like callback parameter in the "load" API.  If it doesn't detect a promise, it assumes the plugin complies with the AMD standard (i.e. no error handling).  

 

While on the surface it may make sense to add it to require(), I do
not think it makes sense to add to define() since the error handling
is specific to an app, not a defined module. I like that require and
define operate similarly, one just names a return value for use by
others (define). 

So, for the define case, you need a global handler anyway, to handle
app-specific recovery.

I don't understand how one could apply a loader's error handler to define().  That doesn't make sense to me.  Error handling inside a define() is app-specific, but does not need to be done globally.  (Maybe I don't understand what you mean?)

 

I'm open to suggestions though, particularly if they are lightweight.
I appreciate that if an app does lots of dynamic require calls, it
would be useful to get targeted errors, but I'm skeptical that the
cost and reliability of doing so is worth it over just a global
handler.

I know you want to get 1.0 released.  That's cool with me. :)  I hope you'll take another look at this afterwards, though.  This is an important oversight imho.

Could we add it to the spec as an optional feature?  

Regards,

-- John

[James Burke]

On Mon, Oct 3, 2011 at 8:59 PM, John Hann <jo...@e-numera.com> wrote:
>> It is difficult to ascertain a 404 or 500 error for a script because
>> of browser weaknesses. It is actually getting better, but IE is still
>> a stinking pile of pain. So the most you can hope for is a timeout,
>> not timely targeted errors.
>
> This is not true.  Only non-AMD javascript files have this problem.  Since
> AMD files will execute at least one define() call in a loaded file, it's
> rather easy to determine if a module wasn't loaded.  Even in IE.  curl.js
> detects errors reliably already by looking for at least one define call.

Ah you are correct, requirejs has the problem since it allows loading
non-AMD modules.

>>
>> I do not like having to mandate that AMD implementations need to trace
>> an bad module back to the require call (or calls) that may want to
>> know about it. That implies extra tracking in the loader to do this.
>
> Not entirely true. curl.js and the dojo loader (iiuc) have the necessary
> mechanics already.  Also, if I understand how loadrunner works, it's got the
> infrastructure to track errors as well.  I don't know how any other loaders
> work, so I can't speak about them.
> curl.js extends this functionality to its plugins, too.  curl.js detects if
> the loader supports the error path by sniffing for a promise-like callback
> parameter in the "load" API.  If it doesn't detect a promise, it assumes the
> plugin complies with the AMD standard (i.e. no error handling).

Right, so for me it is extra tracking since I assume that the global
handler is basically enough.

> I don't understand how one could apply a loader's error handler to define().
>  That doesn't make sense to me.  Error handling inside a define() is
> app-specific, but does not need to be done globally.  (Maybe I don't
> understand what you mean?)

I meant define() is used to define modules, modules that can be used
by potentially anyone. Having an error handler in the define call
would not make sense, since each app that would include the module
probably has its own custom error handling logic. It is likely that
the app would like to have a global error handler, "if anything goes
wrong, call this function", and it would catch errors for those define
calls, so it can do so for require calls too.

If that is the case, then a per require() error handler does not buy
much, but I just realized recently I was assuming the app does maybe
one or two require() calls and has everything as defined modules. I
could see where if it does many require() calls, a per-require error
handler might be useful.

> I know you want to get 1.0 released.  That's cool with me. :)  I hope you'll
> take another look at this afterwards, though.  This is an important
> oversight imho.
> Could we add it to the spec as an optional feature?

I would not mind trying to work out a spec for error handling, but it
should be treated like the loader plugin one, something that is
separate from the core AMD API, but not unusual to find in an AMD
loader. So if you want to spearhead that work and add tests to the
amdjs-tests group for it, I am open to it.

For now, I'm fine with requirejs not supporting it. If it did, since
requirejs supports plain script loading too, it would likely only get
triggered on timeout errors.

James

[Aaron Silvas]

While I do see considerable value in having a global handler for errors, I can tell you for me managing a large framework which dozens of applications interface with, that having per-require error handling is a "must have". Every module we build is independent from one another, and should be able to handle its own errors. Think of it this way, all "success" handling is done on a per-require call (i.e. "require([mod], success)"), so keeping with that pattern seems logical to me.

// per-require recommendation 1: keep it simple

require([mod], success, failure /* new callback */);

// per-require recommendation 2: event bindings

require([mod], success).on('error', failure);

As for global error handling support, if it is added, all that I request is it is done to support multiple listeners.

// global error handling

amdLoader.errRegister(failure);

amdLoader.errUnregister(failure);

Having a single callback for a global handler (i.e. "amdLoader.onError=failure;") is unnecessarily limiting, especially for big frameworks with multiple parties potentially interested in error handling.

- Aaron

[James Burke]

On Tue, Mar 20, 2012 at 10:26 AM, Aaron Silvas <aaron...@gmail.com> wrote:
> Having a single callback for a global handler (i.e.
> "amdLoader.onError=failure;") is unnecessarily limiting, especially for big
> frameworks with multiple parties potentially interested in error handling.

I'm coming around for having a per-require() call error handler, in the form of:

require([], function () { /*this is the ok handler */ }, function
(err) { /*this is the err handler*/ });

I believe curl supports something like this now, and I'll be
prototyping this for a requirejs 1.1 release.

Are other implementers OK with this approach? Any concerns? If so, we
should make a shot at documenting it in the require API doc as an
implementer option.

James

[Richard Backhouse]

Which "require" are we talking about here ? The global/entrypoint one,
the one passed to define calls or both ?

Richard

[James Burke]

On Tue, Mar 27, 2012 at 4:50 AM, Richard Backhouse
<richarda...@gmail.com> wrote:
> Which "require" are we talking about here ? The global/entrypoint one, the
> one passed to define calls or both ?

Ah, good question. What about both? If we want to talk about what we
actually have specified though, so far that is only the local require,
but I'm thinking of allowing it for both in requirejs.

James

[Richard Backhouse]

Supporting on both sounds reasonable. A couple of questions:

1) What would the default behavior be if no error handler was provided ?
2) Is there any particular format/type for the err parameter passed to
the error handler ?
3) Earlier in the thread you mentioned this should not be part of the
core AMD API. As we are modifying the signature of require do you still
think that can still be possible ?

Richard

[James Burke]

On Tue, Mar 27, 2012 at 3:56 PM, Richard Backhouse
<richarda...@gmail.com> wrote:
> 1) What would the default behavior be if no error handler was provided ?

I'm fine with this being undefined for now. For requirejs, I'll
probably still have the global handler too.

> 2) Is there any particular format/type for the err parameter passed to the
> error handler ?

I think it would be fine to start with just "must be of type Error.
I'm open to locking it down more once we have some experience with the
type of errors. Hopefully we'll share what we each end up returning.

> 3) Earlier in the thread you mentioned this should not be part of the core
> AMD API. As we are modifying the signature of require do you still think
> that can still be possible ?

I meant as part of the main AMD define() API page. If it ends up on
the local require, then this page should be updated:

https://github.com/amdjs/amdjs-api/wiki/require

and that it should be mentioned as an optional thing. Well I suppose
it will by default be optional -- if you pass in an error handler and
the loader does not support it, that error handler will never be
called. :)

James

[Adam Peller]

On Thursday, September 22, 2011 11:28:36 AM UTC-4, unscriptable wrote:

There is a disagreement amongst AMD implementors about this.  Some of us advocate a global amdLoader.onError handler.  Others advocate a local error handler.  Some examples of how this might work:

    // simple callback function for errors, "errback"

    require(["mymodule"], callback, errback);

    // CommonJS Promises/A (e.g. dojo/Deferred) or similar (such as jQuery.Deferred)

    require(["mymodule"]).then(callback, errback); 

    // promises, another way

    var dfd = new Deferred(); 

    require(["mymodule"], dfd.promise); 

    dfd.then(callback, errback);

I'm intrigued by the idea of using Promises directly on require.  Callers are typically going to use something like a Promise anyway, so why not just encourage the same pattern?  Chaining Promises could make the call much cleaner and avoid the need (and likely neglected step) to manually wire up an errback function.  Is this still a candidate?  Is the dependency considered too heavy?  Would John's third example represent a compromise?

[James Burke]

On Sun, Apr 8, 2012 at 12:18 PM, Adam Peller <pel...@gmail.com> wrote:
> I'm intrigued by the idea of using Promises directly on require.  Callers
> are typically going to use something like a Promise anyway, so why not just
> encourage the same pattern?  Chaining Promises could make the call much
> cleaner and avoid the need (and likely neglected step) to manually wire up
> an errback function.  Is this still a candidate?  Is the dependency
> considered too heavy?  Would John's third example represent a compromise?

I still think they add more complication to the API than what is
needed, and prescribe too much of an implementation. I like using
promises in my own app code though.

James

[John Hann]

I'm very happy with `require(deps, callback, errback)`.  It seems like it's really safe and easy to implement.  Unless somebody has a major objection, I'm going to implement this.  :)

[James Burke]

On Mon, Apr 23, 2012 at 1:58 PM, John Hann <jo...@unscriptable.com> wrote:
> I'm very happy with `require(deps, callback, errback)`.  It seems like it's
> really safe and easy to implement.  Unless somebody has a major objection,
> I'm going to implement this.  :)

I am working on this too for the next requirejs version.

James

[John Hann]

We (the cujojs team) are getting way too many inquiries (aka "complaints" :) ) about a similar situation.  When using plugins, there's no standard way to propagate loading errors back to the AMD loader.  (Side note: relying on time-outs in the loader to detect loading errors in plugins is not a solution, imho.  It's impossible to determine the correct value.)

curl.js adds a `require.reject(ex)` callback to the `require` injected into the plugin's load method.  curl.js listens to that function so it can handle the error and pass it on to any handlers the dev has added.  We use this in all our plugins to signal that the plugin-based resource (legacy javascript, css file, etc.) didn't load.  

The name "reject" is certainly open for debate -- as is the possibility of changing the load method's signature instead.  Regardless, something like this would seem to go well with the `require(deps, callback, errback)` feature.

Thoughts?

-- John

[James Burke]

On Mon, Apr 23, 2012 at 2:16 PM, John Hann <jo...@unscriptable.com> wrote:
> We (the cujojs team) are getting way too many inquiries (aka "complaints" :)
> ) about a similar situation.  When using plugins, there's no standard way to
> propagate loading errors back to the AMD loader.  (Side note: relying on
> time-outs in the loader to detect loading errors in plugins is not a
> solution, imho.  It's impossible to determine the correct value.)
>
> curl.js adds a `require.reject(ex)` callback to the `require` injected into
> the plugin's load method.  curl.js listens to that function so it can handle
> the error and pass it on to any handlers the dev has added.  We use this in
> all our plugins to signal that the plugin-based resource (legacy javascript,
> css file, etc.) didn't load.
>
> The name "reject" is certainly open for debate -- as is the possibility of
> changing the load method's signature instead.  Regardless, something like
> this would seem to go well with the `require(deps, callback, errback)`
> feature.
>
> Thoughts?

This is for communicating that a loader plugin cannot fulfill a
request to it's load() call?

I favor attaching something to the load() function passed to the plugin:

define({
load: function (id, require, load, config) {
//on success:
load(value);

//on error, just an example of possible api name
load.error(err);
}
});

I favor hanging it off load since it is related to the resolved value,
where the require passed in is for the plugin to require other
dependencies to figure out the resolved value.

James

[Rawld]

I agree they prescribe too much of an implementation. Since the loader
is the lowest layer, it *must* be absolutely minimal. For example,
choosing a loader shouldn't imply a promise impl.

That said, wrapping require in a promise should be
trivial...particularly if we agree on the errback idea.

--Rawld

[Rawld]

I'm not sure I agree with this idea in either form. Why do we have to
introduce any loader support for plugin errors? Isn't that up to the
particular plugin? Since the loader can't respond in any rational way,
shouldn't the loader just be blind to plugin errors.

Here's a sketch of how to write a plugin that detects and publishes an
error condition along with a client module that uses the feature...with
zero additional loader machinery:

// my/plugin
define([], function(){
var result = {
error:{},
// could define any number of error "types"

load:function(id, req, load){
if(success){
load(value);
}else{
load(result.error);
}
}
};
return result;
});

Now, use it...

require(
["my/Plugin", "my/Plugin!1-2-buckle-my-shoe"],
function(plugin, pluginResource){
if(pluginResource===plugin.error){
// error recovery
return;
}

// normal path
}
);

Of course the require pattern could be easily wrapped (outside the
loader) in a promise if that's interesting to the client.

The point is: reporting an error is totally useless unless some
machinery is going to listen for the error and do something. It is
impossible for the loader to do anything rational with a plugin error
because the loader doesn't have any knowledge of the plugin's semantics.
otoh, client code can/does have knowledge of plugin semantics and may
choose to do something interesting (or not). Either way, a plugin that
reports an error in this manner does not stall the loader and the loader
maintains a legal state.

--Rawld

[Rawld]

I'm not at all convinced that this error handling/reporting is going
down the right track. I described my preference on another message on
this thread re plugins. Let me think out loud about normal modules...

There are three reasons a normal module could fail to load

1. programming error
I don't see any point in attempting to fix this. Writing code to recover
from programming errors is almost never successful. I'd prefer to keep
the loader clean and discourage this activity.

2. network error
I can see that this may be worthwhile. For example, over a bad net the
program may allow a retry or switching servers or whatever. But, if this
is the goal, then it should extend to define as well as require. Also,
there should probably be a couple of recovery options...maybe

* reset the loader to a clean state where all outstanding/failed
requests are canceled.
* provide a callback for each module that fails and allow client code to
optionally instruct how to resolve the problem...try again, try another
url, reset the loader...any others?

3. intentional request for a module that may be properly *not* be
delivered iaw the server logic.
This is akin to using a try-catch block to effect an expected control
flow. I would say this is bad design and shouldn't be encouraged.

So this leaves me thinking [2] is a good case, *only* for normal modules
(let plugins define their own strategy).

I'll prototype/spec something after feedback.

--Rawld

[James Burke]

On Tue, Apr 24, 2012 at 10:28 PM, Rawld <rg...@altoviso.com> wrote:
> 2. network error
> I can see that this may be worthwhile. For example, over a bad net the
> program may allow a retry or switching servers or whatever. But, if this is
> the goal, then it should extend to define as well as require. Also, there
> should probably be a couple of recovery options...maybe

Indeed, this is the only case that caused me to reconsider supporting
require-specific error handlers. The case that convinced me: an
offline web app that has a "sign in" button that needs to use a
network hosted script to load for the identity provider
(facebook/browserid).

In this case, the app is designed to show some UI/interaction even if
the user is offline, but optionally allow sign in if the network
request goes through.

The other case that has come up in requirejs land: developer wants to
use a CDN for jquery, but if the CDN is not available, get an error
callback, adjust the paths config to be a local path for 'jquery',
tell the loader to 'undefine/reset' any internal state relating to the
pending 'jquery' load, and try fetching it again.

I also believe that loader plugins should allow an error callback path
too. Using the load() call to pass back an error does the wrong thing
-- it does not allow for this second case of "use this resource, if
not available, reconfigure, reset and try again".

At least for requirejs, calling load() means "dependency satisfied" so
if both 'a' and 'b' depend on 'c!foo', they get a value and then 'a'
and 'b' are "defined". no reset possible. Having an error channel for
plugins would allow holding off final evaluation of 'a' and 'b' until
the reconfigure/reset and retry was finished.

James

[Rawld]

Excellent. Sounds like we're mostly aligned. More below.

On 04/25/2012 10:02 PM, James Burke wrote:
> On Tue, Apr 24, 2012 at 10:28 PM, Rawld<rg...@altoviso.com> wrote:
>> 2. network error
>> I can see that this may be worthwhile. For example, over a bad net the
>> program may allow a retry or switching servers or whatever. But, if this is
>> the goal, then it should extend to define as well as require. Also, there
>> should probably be a couple of recovery options...maybe
> Indeed, this is the only case that caused me to reconsider supporting
> require-specific error handlers. The case that convinced me: an
> offline web app that has a "sign in" button that needs to use a
> network hosted script to load for the identity provider
> (facebook/browserid).
>
> In this case, the app is designed to show some UI/interaction even if
> the user is offline, but optionally allow sign in if the network
> request goes through.
>
> The other case that has come up in requirejs land: developer wants to
> use a CDN for jquery, but if the CDN is not available, get an error
> callback, adjust the paths config to be a local path for 'jquery',
> tell the loader to 'undefine/reset' any internal state relating to the
> pending 'jquery' load, and try fetching it again.
>
> I also believe that loader plugins should allow an error callback path
> too. Using the load() call to pass back an error does the wrong thing
> -- it does not allow for this second case of "use this resource, if
> not available, reconfigure, reset and try again".

I'm starting to see your point. So, if a module depends on a plugin, and
the plugin failed to load, then the module fails to load, and the
errbacks--maybe a whole chain of them?--get applied. Is that what you
envision?

[John Hann]

The wire.js plugin ("wire!") is a good example.  It loads AMD-wrapped json descriptors ("specs") that typically specify additional modules to load.  https://github.com/cujojs/wire/wiki/Wire-specs

Several devs have complained that there's no standard way to get direct feedback if a spec fails to execute because an AMD module didn't load.

Actually, the same problem happens if you use the wire module directly and plugins are being used in the spec:

wire('my/spec').then(success, failureNeverGetsCalled);

Having a direct error path via `require` and plugins will solve this problem.

We were about to add a sniff for the `require.reject` callback, but `load.error` is fine.  

Rawld, any thoughts on the API for reporting errors back?

-- J

[James Burke]

On Wed, Apr 25, 2012 at 11:49 PM, Rawld <rg...@altoviso.com> wrote:
> I'm starting to see your point. So, if a module depends on a plugin, and the
> plugin failed to load, then the module fails to load, and the
> errbacks--maybe a whole chain of them?--get applied. Is that what you
> envision?

Yes. I did some simple tests, got something working for requirejs 2.0 code:

https://github.com/jrburke/requirejs/tree/dev2.0/tests/error

I'm using load.error() right now:
https://github.com/jrburke/requirejs/blob/dev2.0/tests/error/plug.js

but I am very happy to change that to something else if you all have a
better suggestion. I have an interest in wrapping up the choice of
that API name soon though. :)

One other qualification I found when doing this work: I am able to
support having a timeout/error on loading a JS module, have that
bubble up to a require() error handler, and then in that error
handler, doing a requirejs.undef() on that failed module, point the
path to some other version of the module, and then trigger a
successful load via another require() call.

However, for plugins, this is not supported -- there is not enough
info for an 'undef()' call to do a reset -- the loader plugin may have
internal state, and at least for how I manage the chain of events for
tieing modules together, there is not a way to reset the states for
the interim "unnormalized" resource IDs.

So, I have the qualification in requirejs that while you can get an
error notification of a loader plugin failure, it is not possible to
easily "reset" and try again for loader plugin resources, that only
works for JS modules.

Resetting internal state is not something we need to sort out for this
particular issue (choose a name for the plugin error API call), but
just sharing some info around it.

James