-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Throw all IndexedDB errors as promises #5
Comments
The angular exception handler does this pretty well. Is there a reason Otherwise this would make for a very confusing API. If there is a specific On Saturday, October 25, 2014, James Messinger notifications@github.com
|
The IndexedDB APIs can throw some errors immediately (rather than through the General-programming errors aside, the end result is a much cleaner API that wraps the entire IndexedDB API in promises, which is the main reason for using Angular-IndexedDB. It doesn't seem very consistent to wrap some parts of IndexedDB in promises, but not other parts. |
Specifically, a common use-case for Angular-IndexedDB is to make it easy to write Angular services that perform async DB operations and return promises. Something like this: var user = { id: 1, username: "jdoe", password: "password" };
$myCustomService.saveUser(user).then(showSuccessMessage, showErrorMessage); But if Angular-IndexedDB sometimes throws synchronous errors and sometimes throws asynchronous errors, then the above code becomes much less clean: var user = { id: 1, username: "jdoe", password: "password" };
try {
$myCustomService.saveUser(user).then(showSuccessMessage, showErrorMessage);
}
catch (err) {
showErrorMessage(err);
} Alternatively, I could move the angular.modlue('myApp').factory('$myCustomService', function($indexedDB, $q) {
return {
saveUser: function(userObj) {
var deferred = $q.defer();
$indexedDB.openStore('users', function(userStore) {
try {
userStore.upsert(userObj).then(
function(result) {
deferred.resolve(result);
},
function(err) {
deferred.reject(err);
}
);
}
catch (err) {
deferred.reject(err);
}
});
return deferred.promise;
}
};
}); Instead, if Angular-IndexedDB always threw errors asynchronously via angular.modlue('myApp').factory('$myCustomService', function($indexedDB) {
return {
saveUser: function(userObj) {
return $indexedDB.openStore('users', function(userStore) {
userStore.upsert(userObj);
});
}
};
}); |
So I'm closing this because Angular already does this for us.... So... should some promise handler throw an exception, the promise is rejected with the exception AND the exceptionHandler is notified of this. |
Hey Bram, could you help with this? http://stackoverflow.com/questions/36869596/angularjs-return-object-of-methods-after-indexeddb-call |
Any code that interacts directly with the IndexedDB API needs to be wrapped in a
try...catch
block so that any errors can be passed topromise.reject()
rather than being thrown up the stack. Currently, I have to have two types of error handling logic in my code, because some errors are thrown synchronously, and others are "thrown" asynchronously viapromise.reject()
. Here's an example:Ideally, I could get rid of the
try...catch
block entirely and just write the following code instead:The text was updated successfully, but these errors were encountered: