THe problem here, as I told you in the github issue, is that we don't know what has caused the crash.
It could be:
- a problem in the user's own code - such as the example you gave
- a bug in any of the nodes they have installed
- a bug in the core of node-red
There is literally no way for us to know what has caused it.
Again, as I replied in the issue, node.js is very clear on what to do with uncaughtExceptions:
From node's own documentation on handling 'uncaughtExceptions'
Unhandled exceptions inherently mean that an application is in an undefined state. Attempting to resume application code without properly recovering from the exception can cause additional unforeseen and unpredictable issues.
The correct use of
'uncaughtException'is to perform synchronous cleanup of allocated resources (e.g. file descriptors, handles, etc) before shutting down the process. It is not safe to resume normal operation after'uncaughtException'.
So as much as I agree it would be nice to provide more feedback, there is no reliable way for us to do so.
At best we could add more to the error message in the log output to point the user at possible causes. But we certainly couldn't keep the server running just to present a webpage. If you are in production, you'd want the system to restart quickly instead of serve a webpage.
