During development, I make sure I add code to support the given exception if it appears to likely to occur. Thus, I make my code as robust as possible. If it is something I don't believe will be common or frequent, notation to the log at a minimum, may send to warn, i.e. debug so user gets feedback. Really the goal, and how I will document the expectation in the read-me, in the code, is that users should communicate unhandled exceptions back to me, say as issues via GitHub for example. I plan provide active and serious support for the code I develop, as such, release to the node-red community.
If all you do is warn or log, and it is a very unusual occurrence then quite possibly no-one will notice for some time, so the system will be failing in some way but not indicating that anything is wrong. There is a good argument that that since there is no way of knowing whether an unexpected exception is serious or not then it may be better to allow node-red to crash so that the users attention is drawn to the issue. That will allow the system fail-safe mechanisms to cut in and do whatever is necessary to keep the system safe. If instead you allow the system to continue running then perhaps a critical alarm will go unsignalled, for example, with potentially catastropic results.
During development there is no need to catch unexpected exceptions as node-red will crash and it will be clear that there is a problem.
1 Like
I see and agree with you to a point. I do understand your perspective. Joe user that has node-red setup at home or in a small shop, failure of node red maybe acceptable, even wanted.
However, having worked and designed monitoring systems for many years for VMware, KVM, Hyper-V (all virtualization platforms), where exceptions are common early in maturity of solutions, I disagree with you.
Let me qualify, allowing all monitoring to fail completely is just not good from an enterprise or total environment mindset, you can't let your total monitoring fail, because of one unqualified exception. In virtualization, you flag on trends before failure, never wait for actual failure. Thus, if you are not watching the log or debug stream for events, for shame. Log scanning for keywords will capture issues, and warnings generated can thus result. In my personal environment, I scan logs for keywords, generating notifications to console, dashboard, phone, email, as applicable.
I even setup a multi-color diode on my raspberry pi devices, that flashes blue every few minutes, to signal good state, and flashes red when an unhandled exception has occurred that needs attention. In fact, I finished creating a flow that does this diode control. So I can retire my python script (under cron) when I finish my migration to node-red. Device pings, firewall rule events (yes I have an internal firewall), etc. all will feed into this notification solution over time, as I have time to implement such.
Again, I come from an enterprise mind set.
OK, that is a very reasonable approach, however what it means is that you are not 'just' logging unexpected exceptions but are doing that (or something else) in a way that allows you effectively to detect such exceptions and indicate them to the user, but keep the rest of the system running.
I fear that if you need to go to those lengths then perhaps node-red is not the right tool for the job, as the core nodes do not (as far as I can see) adopt that policy.
The intermediate route is what actually happens at the moment (at least on a linux system using the recommended install script) that node-red will crash and immediately restart. On some systems that may better than trying to carry on with a possibly compromised environment. The restart can of course easily generate appropriate notifications.
Actually I think node red is the right solution, since the use case is personal. That said, my experience in enterprise systems definitely influences my approach to how I use it. Some of what am doing or plan to do, could be over kill, to be sure. 
At the risk of sounding cheeky? My world my rules?
The node-red solution is great, and I can see it being adopted all over the place, even at some point, as an element of enterprise monitoring as it matures.
Some enterprise monitoring solutions that feel a bit like node-red, are ManageIQ or its commercial variant CloudForms. These are monitoring tools, no visual development solutions, but some key concepts are shared given how node-red dashboard can be leveraged, and may mature over time.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
