On Tue, Aug 25, 2009 at 9:55 PM, James Robinson<[email protected]> wrote: > I would suggest having explicit successCallback / errorCallback callbacks > set on an object sent in to each async call. This way the extension writer > can keep their error handling code separate from their normal application > logic, avoid accidentally treating an error callback as a success callback, > and be able to use only the parameters to the callbacks rather than globals > sitting on chrome.extension. chrome.tabs.create's signature would then look > like: > void create([{[string url], [int windowId], [int index], [bool selected]}], > [{[void successCallback(Tab)], [void > errorCallback(Error)]}]); > successCallback() would only be invoked on a successful completion of the > call and the Tab parameter would always be a valid chrome.tabs.Tab object. > errorCallback() would be invoked if the call failed with an Error parameter > which would replace the chrome.extension.lastError object. > - James
At first I was skeptical, but now I like this idea. Only would add that if sucessCallback or errorCallback are null undefined, they should be ignored (errorCallback in particular should be optional, yea, I could pass a dummy function, but that reminds me too much of Java's stupid demand for empty catch statements).. Conceptually this model makes more sense and allows one to structure code more logically, also allows you to easily ignore errors when you really don't care, which is most times. 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 -~----------~----~----~----~------~----~------~--~---
