Open tmdoit-zz opened 4 years ago
I am actually not sure.
How would be a normal way of handling this in other node-red setups? Would it be a specific message out or?
Hi Mathias, Some thoughts, Probably the best way to really handle errors, is to fix them in alasql, the usage of throw in the src files is where the problem lies, in normal terms, the caller function should handle the error returned from a called function, not the called function bombing out with a "throw error". So, if any function called, like delete,drop,create,detach etc has an issue, then the cb should be an object containing either a 0/1 and an error message etc. The caller alasql function can then decide what the next action should be, in the case of core database issues, then a legitimate throw would be used, however in the case of trying to insert into a non-existent database, then an error message is more applicable Therefore, from a Node-Red point of view, then yes a single object returned on a output is the go.
Hi all, regardless of error source (your node / alasql) you should try at all costs to prevent crashing node-red
The recommended method for contrib nodes in node-red is...
try {
//do stuff
} catch (e) {
node.error(e,msg);
return; //dont send a msg
}
NOTE: for promises, use the .catch mechanism to feed errors forward again using node.error(e,msg)
;
This permits the node-red catch
node to catch the error allowing the flow to handle the error appropriately.
Not handling errors in your node can crash node-red - not good.
NOTE: if you wish, you can still send a message (and include the error) but many flow developers will see a message & may not check for a msg.error
property. I have in some contrib nodes, provided a UI option to "throw errors" or "add error to msg object"
@Steve-Mcl Good point - and thank you for reminding me.
There is no option to handle errors like path to file not exists or bad file format, am I right?