Careful what you imagine. 
3 Likes
so far it does not .... will test tomorrow ... maybe it will 
It is not only the 'uncaughtException', but every async operation like unhandled errors in EventEmitters (missing on('error',...)) and unhandled promise rejections. If any of these happen in your function node, in some cases you cannot even tell that it came from there, as the code is executed from the event loop.
As @knolleary stated, it is hard to determine, where the problem has occurred exactly. So the only reasonable thing is to let the process crash and perform an automatic restart by some process manager like pm2, nssm, etc - at least for production systems. Otherwise you could end up with inconsistent states.
2 Likes
Did someone say calculator crashes.... ? only occasionally - https://www.google.com/search?q=crash+windows+calculator+app&oq=crash+windows+calculator+app&aqs=chrome..69i57.6184j0j7&sourceid=chrome&ie=UTF-8
3 Likes
no BSOD .... so it does not apply to this topic ... you will have to dig deeper :))))
No bsod but just bails out.
1 Like
Sorry, late to this discussion but if the error happens inside a function node, doesn't that crash the VM? If so, can't the VM itself be wrapped in a try/catch? Not sure that would catch everything but it might help?
Sorry if that is just too simplistic, I've not had a chance to look at the core code where the VM is set up.
Also, am I the only one who spotted the typo in the error message? "seams" should be "seems" - is that message from the browser or from Node-RED?
@TotallyInformation if it were that easy we would have already done that....
I cannot see any error message in this thread that contains either 'seams' or 'seems'. Where are you looking?
NOTE:
Dyslexia is a serious condition for those who suffer, or cannot access spell checkers.
I think I know what the problem is... It's probably the "undefindenFunction" its not defindened... what is this undefinden Function? perhaps its just a reference that's spelled wrongly. Perhaps you should just definden it...
dyslexia sukcs!
2 Likes
In the screenshot from the web page
That image is a mock-up example made by @dsl400. It is not a real image of any message we produce - it was a suggestion for the type of thing we could do.
There does not need to be any further critique over the contents of the image. It is not practical for us to display any such error message in the browser.
sorry ! 
I thought it was funny... (because I have dyslexia... 
)
Sorry, I hadn’t recognised it as a mockup, thought it was the actual error shown but reading this topic again carefully obviously makes clear no error page would have been shown. The realistic looking error page got me confused.
2 Likes
it is exactly what you say it is, a typo and if you read the whole discussion you can see that this exactly the subject of this thread, a typo can stop the node-red server
funny! isn't it ?!
I figured as much, but the thing I missed was the nuance of the image being a fake, for the point of having a typo which made it past the editor(s). OK, Anyway, I thought it was funny, even if nobody else got it.
4 Likes
With all due respect, no parser can consistently recognize a "typo." There are only errors, and they are equally serious. As @knolleary says, without explicit error handling, there is no point in asking a supervisory program to guess what the user meant instead of what he typed.
Otherwise, this has been an entertaining discussion.
4 Likes
Maybe I'm not saying it the right way, I will try again, I typed something into a function node, I click done then I clicked deploy a few seconds later I got a notification about being disconnected, refreshing the page toked me to the browser's default page not found and that was it.
Now I have nothing to play with. This instance of Node-Red is gone forever for me until I learn how Node-Red manages flows and where it stores them and how to get to that place to figure out what crashed in that single line file.
Node-Red promises to be something very easy to use untill it crashes, after it does it is no longer easy, you have to know a lot of things to get it back in the working condition.
This feature request is about providing an easy solution to get the server back in the working condition for those who just started learning.
I agree, but none of your proposals are practical to actually implement.
I'm not going to tell you how to do it or if you should do it or not. You have to decide that, you are the expert. I just thought that it would be much more easy for "the kids" to have a button that makes Node-Red work again if they screw something up
Where it stores the file is listed in the startup messages Node-RED logs also covered i. the getting started page in the docs.
As is the “safe mode” which you could use to recover the “broken” flows file
https://nodered.org/docs/getting-started/local#command-line-usage
2 Likes
Which it hardly ever does.
We all want to improve that. But we have to work with the technology we have. Node-RED is built on node.js which itself has certain limitations. Until we can all move up to v12+ of node.js where a lot more introspection options become available, there is a limit to what can be done unless some clever, knowledgeable people manage to come up with something workable.
At the end of the day, we are all using Node-RED - which is free. That uses node.js and ExpressJS, D3, jQuery, ... - all of which are also completely free of charge.
We want to continue to push the boundaries but we also need to recognise the limitations. Just because something sounds easy, doesn't mean it is.
I think it has been made clear that this isn't easy to implement.
Also, there is a method that generally makes recovery easy - at least in many cases. That is the --safe startup option that has also been mentioned.
The number of serious issues we find with Node-RED are actually few and far between - certainly a lot less than I would expect from freeware tools of this level of complexity.
- Incorrect use of SUDO
- Problems with virtualised installations
- A badly written or buggy contributed node - or more likely a problem with a dependent package.
- Compilation issues with C/C++ dependencies in packages after a node.js upgrade
My live Node-RED home automation server has at current count 924 node.js packages (including node-red itself). That includes 72 node types (1023 deployed node instances). It is absolutely rock solid.
Maintenance is absolutely minimal, an occasional npm update and once in a while, generally when node.js changes major version, I delete the node_modules folder to force a full rebuild though you can do it without deleting if you can remember the right npm command.
It has been running solidly now for several years. All I've paid for is the hardware!
I should also point out that Node-RED is virtually unique. There are a few other flow-based tools out there but they either cost money (lots!) or are nowhere near as easy to use.
I say all of this, not to be defensive, but simply to remind all of us (myself most of all) how much has gone into the development of Node-RED.
Please absolutely do keep raising issues like this and trying to help find solutions but let us also remember the art of the possible. I don't know how many people are currently working full time on Node-RED core development (2?) but it certainly isn't many. It is a massive toolset already and continuing to grow at pace thanks to those who contribute to core.
3 Likes
refreshing the page toked me to the browser's default page not found and that was it.
It crashed, thus there is no webserver anymore, it cannot tell you anything other than the last entry in the log.
Certain "typo's" will crash programs, others won't, that is because it is not so simple to catch user errors.
For your specific example: you could (or should) have used a try, catch block, so that your code doesn't crash node-red.
1 Like