On Wed, Aug 26, 2009 at 6: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.
I'm not sure, if you don't provide an error callback it simply means that you except the non-error callback to only get called in a best-effort basis, which in most cases it is good enough given how rare errors are and that in many cases if there is an error there is nothing you can do about it anyway. > 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"? > 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). Again, by making the error-callback optional, it makes it easy for developers to ignore most errors without having to worry (or they can even write a generic error handler that they can easily use everywhere for debug purposes or whatever). Given the alternatives this seems like the simplest and least bad. I will just add that the pain of error handling and the convoluted execution paths are one of the reasons I hate callbacks, they make debugging, error handling and synchronization a pain. But again, given JavaScript's lack of decent (CSP or Erlang-style) concurrency, I guess there are few options. Peace 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 -~----------~----~----~----~------~----~------~--~---
