On Wed, Aug 26, 2009 at 11:58 PM, Aaron Boodman<[email protected]> wrote:
>
> On Wed, Aug 26, 2009 at 2:40 PM, James Robinson<[email protected]> wrote:
>> 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 thinking is exactly the opposite. These races can be caused two ways:
>
> a) The developer holds onto some state too long and it goes stale.
> This is a development-time error. Writing to the console is a good way
> to handle it, throwing a catchable error is not useful.
>
> b) A real, honest-to-goodness race. Realistically, this will happen
> very, very, rarely. Some advanced apps may actually want to catch this
> situation, but most developers won't.
>
> Because of these two, my thinking is that the API should encourage
> developers to *not* handle these races. I just don't feel like the
> payoff is there.
I agree completely, forcing people to handle errors when they don't
care is a really bad idea, just look at Java.
>>> 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.
>
> Ok, it's mostly a wording distinction "log and continue", vs "log and
> continue down success path", but I see the point you are trying to
> make.
>
>> 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
>> }
>
> Yes, that is what we were trying to encourage.
>
>> 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});
>
> I think this encapsulates the differences between our ideas really well:
>
> - In our current design, the result of a developer ignoring errors is
> that code continues down the success path.
> - In your proposal, the result is that nothing happens at all. Execution
> stops.
>
> The question really comes down to which of these two behaviors is better.
>
> Additionally, there is another minor question of which of the
> following two are more annoying:
>
> chrome.tabs.update(..., function() {
> if (!chrome.getLastError()) {
> ...handle success...
> }
>
> continue with program
> });
>
> chrome.tabs.update(..., function() {
> handle success
> continue with program
> }, function() {
> continue with program
> });
I prefer:
chrome.tabs.update(..., function() {
handle success
continue with program
});
And in the rare case that I want to catch the error, I pass an extra
function, which might even be a generic function that logs the error
or whatever might be useful for debugging.
So being able to do
chrome.tabs.update(..., function() {
handle success
continue with program
}, null);
would be fine by me too.
> I personally find the first one less annoying. I can see your argument
> though, and I need some more time to think about it.
The problem with the first one is that the callback gets called even
when there is an error, which sort of forces you to check for the
error flag unless you are ok with your code acting erratically (if it
touches any of the arguments it will bomb, if it doesn't it will run
just fine).
The explicit error callback makes behavior much more predictable and
better logically structured in the rare cases where you want to handle
the error.
uriel
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
