Open TheWitness opened 1 year ago
This change will also affect routerconfigs and export. Not sure I approve of it at this level. The plugin itself should have handled that filtering if it is not desired. For routerconfigs, this can be important to see.
It will have to insert it's own error handler. Would that be acceptable? The other approach that I like would be to set a Cacti Error Handler global for all intercepted and ignored errors, and when the socket, file, ssh, etc. operation fails, the caller simply would check that error handler global or even better call a Cacti Error handler function that would both return the error and clear it at the same time. What do you think?
The problem is that an error handler should do as little as possible. It shouldn't be chaining too many handlers because that increases the change of an error during error handling.
Will have to think about how to handle that but certainly for routerconfig and gexport (which uses external functions) seeing these errors is good for a data centre
The other approach would be to have a softer error, or really a warning then.
Describe the bug
During some plugin operations, we get a socket error that displays the error below. We should mask this error reaching the Cacti log.
Expected behavior
Since the plugins will catch this error by virtue of the error message string we should block it from hitting the Cacti log.