You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
console.info(did + 'sending job to platform handler');
try {
handler(job).then(function (obj) {
_jobSuccess(jobResp, obj);
}, function (err, obj) {
_jobFailure(jobResp, err, obj);
});
} catch (e) {
console.error(did + 'problem from platform ' + e.toString());
jobResp(""+e.toString(), false);
setTimeout(function () {
throw new Error(did + 'RESET PLATFORM on call to [' + job.verb +
']: ' + e.toString());
}, 0);
}
In the above case I'm return the promise, even though I do more stuff to handle the success. It seems ilogical that I should be returning the promise from another func, when I do things based on the success, and then i have to manufature my own promise to fulfill manually and send back.
If I return the result of testFunc - then the thrown error shows up as a failed promise.
If I don't return the result of testFunc - then the error is caught within promising.
Either way, there's no way for me know catch thrown errors. I need to know if an error is thrown. If an error is thrown, I reset the process completely. If a promise is failed, I don't do anything. The use control flow is completely different.
Also, I can't rely on platform devs to return all their promises. If an error is thrown, no matter what, I need to catch that and handle it.
How can I get this result?
The text was updated successfully, but these errors were encountered:
Some relevant discussion a few years back: kriskowal/q#30
From what I understand, if they used an end(); on the "mother" caller of a promise chain, then wrapping that in a try/catch will catch thrown exceptions?
I don't understand why it's OK to consider a thrown exception or a rejected promise as the same. A thrown error could be any weird corruption during execution, whereas a rejected promise generally would imply things are still working, that operation just didn't work. So, a thrown exception could be syntax errors, or some serious bugs in code - those need to be hadled differently than simply a promise saying "we couldn't save a file" or something.
Hey man, I'm still having a hell of a time figuring out how to catch thrown errors from within platforms in the listener.
First off, I created a test case within sockethub, if you want to see the failure im talking about. If you update your sockethub repo to the latest, you'll find a test case for this:
https://github.com/sockethub/sockethub/blob/master/test/70-fullstack-suite.js#L285
I have a test platform which throws an error from within a promise
then
:https://github.com/sockethub/sockethub/blob/master/lib/platforms/test.js#L17
Then, when the listener calls the platforms function, it wraps the call in a
try
block:https://github.com/sockethub/sockethub/blob/master/lib/sockethub/listener.js#L262
In the above case I'm return the promise, even though I do more stuff to handle the success. It seems ilogical that I should be returning the promise from another func, when I do things based on the success, and then i have to manufature my own promise to fulfill manually and send back.
If I return the result of testFunc - then the thrown error shows up as a failed promise.
If I don't return the result of testFunc - then the error is caught within promising.
Either way, there's no way for me know catch thrown errors. I need to know if an error is thrown. If an error is thrown, I reset the process completely. If a promise is failed, I don't do anything. The use control flow is completely different.
Also, I can't rely on platform devs to return all their promises. If an error is thrown, no matter what, I need to catch that and handle it.
How can I get this result?
The text was updated successfully, but these errors were encountered: