On Wed, Aug 26, 2009 at 12:19 AM, Rafael Weinstein <[email protected]>wrote:

>
> Invariably when writing my own code I forget to check
>> chrome.extension.lastError in my callback and die horribly at the first
>> attempt to reference a parameter on the callback.  If they do something like
>> store a reference to the callback parameters in a container for later
>> processing then the undefined reference might not show up until much much
>> later and be impossible to track down.  In cases where the callback is
>> parameterless (for example chrome.tabs.update()) an extensions developer
>> will typically forget to check lastError and proceed with their application
>> logic regardless of if the call succeeded.  This seems less than ideal :(
>>
>
> Omitting error handling code in the case of separate success & error
> callbacks has the result that the call simply disappears into nowhere and no
> resulting code ever runs. If an error has occurred, it seems to me like the
> more obvious failure is preferable.
>
> In either case, an async call error will always generate a console.error()
> message.
>
> On Tue, Aug 25, 2009 at 1:44 PM, James Robinson <[email protected]> wrote:
>
>> On Tue, Aug 25, 2009 at 4:03 PM, Aaron Boodman <[email protected]> wrote:
>>
>>> Thanks for the feedback, James.
>>>
>>> Part of the motivation for this design was that errors are (or at
>>> least should be) rare, and so we should not overoptimize the paths for
>>> handling them.
>>
>>
>> Hopefully error will be vanishingly rare, but some errors are unavoidable.
>>  Errors that are rare also tend to be less likely to show up in the
>> development cycle which makes it more tempting to not code for error paths
>> and blow up horribly in the wild (I didn't catch the chrome.tabs.create()
>> error condition until trying on a different machine).
>>
>
> I think it's true that these errors will tend to be very rare. I feel like
> it's nearly impossible to handle an error in some useful way without
> understanding the error case. Can you give an example of doing something
> useful in handling an error that will typically only be discovered "in the
> wild"?
>

Some classes of errors are unavoidable in an async environment.  For
example, all asynchronous calls that take in a window or tab ID can fail if
the window or tab goes away before the extension can process the relevant
closing event.  The goal should be to make sure that extensions will handle
errors gracefully when they do occur.

>
> My worry is that if we encourage developers to always handle errors,
> extension code will be more verbose, but almost never do anything other than
> report the error somewhere (which already happens).
>

The default behavior in the error case right now is not to log the error and
continue - it's to log the error and then continue on the 'success' codepath
which has a good chance of throwing an exception somewhere in the future.
 Developers will, by default, not check for chrome.extension.lastError at
the top of every async callback.  Ideally they would and they would check
that malloc() didn't return NULL and that close() didn't return -1.  In
practice the obvious thing to write is:

function tabCreatedCallback(tab) {
  // App logic
}
chrome.tabs.create(params, tabCreatedCallback);

When an error occurs the application logic will throw an exception when it
touches the callback's parameters - possibly not even within the same
callstack if the parameter is stored somewhere else.

In order to get robustness right now a developer has to write something like
this:

function tabCreatedCallback(tab) {
  if (chrome.extension.lastError) {
    return;
  }
  // App logic
}
chrome.tabs.create(params, tabCreatedCallback);

This is not too bad, but the equivalent logic could also be expressed in the
proposal like this:

function tabCreatedCallback(tab) {
  // App logic
}
chrome.tabs.create(params, {'success': tabCreatedCallback});

which in addition to being slightly more compact is a bit more explicit.
 When the developer does want custom error handling the code looks like
this:

// Current scheme, explicit error handling
function tabCreatedCallback(tab) {
  if (chrome.extension.lastError) {
    // Error handling logic
    return;
  }
  // App logic
}
chrome.tabs.create(params, tabCreatedCallback);


// Proposed scheme, explicit error handling
function tabCreatedCallback(tab) {
  // App logic
}
function tabCreatedError(error) {
  // Error handling logic
}
chrome.tabs.create(params, {'success': tabCreatedCallback, 'error':
tabCreatedError});

The exact line counts will vary depending on the developer's style
preferences but I do not think the proposal will lead to a large increase in
verbosity.

- James


>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Chromium-extensions" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/chromium-extensions?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to