LabVIEW
Error handling using ”Retain all errors”
Solved!
The Merge Errors node can be set to retain all errors (right-click menu). But Simple Error Handler.vi is not smart enough to convert the errors to something readable and just outputs the JSON text. Why?
If I use “Convert to Legacy Error Cluster.vi”, the source text of a JSON error is not as in the original. Line feeds and carriage returns are replaced with \r\n. Why?
By using the Vis in the “Multiple Errors” subpalette, I can get the errors out again and I can get the errors in a readable format again. But I have to know what type of error I have or create code to find out. And then I need different code depending on the error type to get readable source text. And format that text myself.
Is there a replacement for Simple Error Handler to manage this?
Is there a better way to do this than to write my own error handler?
Shouldn’t there be a VI that detects and outputs what type of error I have at least, so I can determine what to do with the error? E.g. Legacy / Single / Multiple.
I could not find much about it in the help, no example and nothing from googling.
@thols wrote:
Is there a replacement for Simple Error Handler to manage this?
I've made my own.
It's not as hard as it looks. At least not if you don't use the advanced 'simple error handler' options, like custom errors.
You can reuse lots of the error handling code to 'resolve' the errors (add possible causes, etc.), the only problem is that the output string has HTML-ish tags (<b>) removed.
@thols wrote:Is there a better way to do this than to write my own error handler?
I was waiting for an opportunity to do a presentation on this. I'd share my VI (which isn't that much of a deal). I guess I could share anyway, now that guest presentations on NIWeek are off.
It's more of a starting point then a final solution.
The multiple errors have been great for me. Apart from the lack of documentation and a dialog, it added a lot to my applications with very, very little effort.
Search LabVIEW like a graph! @Wiebe, I guess it is fairly simple to my own error handler. But it just feels like the feature is half finished and that makes me think I must have missed something.
@thols wrote:Shouldn’t there be a VI that detects and outputs what type of error I have at least, so I can determine what to do with the error? E.g. Legacy / Single / Multiple.
The differentiation between single and multiple is just silly to me. 'Multiple' is an array, and a single element fits perfectly in an array. It just complicates things, without any advantage.
\vi.lib\MultiError\Is Encoded.vi returns true if it's an encoded error (Legacy vs Single\Multiple).
Error Cluster to Array of Errors.vi returns 1 or multiple errors (Single vs Multiple).
I think I saw a post recently (don't know where or how old), from Darren I think, that NI was looking at being able to present multiple errors. I think that was what made me look into this again, after stopping last time when I saw these issues. So maybe it is coming, or maybe it is what was implemented as it is now.
wiebe@CARYA wrote:
...
\vi.lib\MultiError\Is Encoded.vi returns true if it's an encoded error (Legacy vs Single\Multiple).
Error Cluster to Array of Errors.vi returns 1 or multiple errors (Single vs Multiple).
Thanks for pointing me to vi.lib. I think I will make my own error handler. Unless someone else has a good one to share or already made a vipm-package for it.
@thols wrote:
I think I saw a post recently (don't know where or how old), from Darren I think, that NI was looking at being able to present multiple errors. I think that was what made me look into this again, after stopping last time when I saw these issues. So maybe it is coming, or maybe it is what was implemented as it is now.
I think it took me 1 hour. Maybe 2 more to fine tune.
Of course it does only what I need it to do. Maybe a more general dialog is desirable, and that would take more time.
The biggest problem I had to solve is the mess in the available traditional dialogs. NI can change those, I can't. It shouldn't be that hard to add or change a dialog.
It would be nice if the traditional dialogs would simply accept the multiple errors of course.
Perhaps this should be on the idea exchange?
@thols wrote:
wiebe@CARYA wrote:
...
\vi.lib\MultiError\Is Encoded.vi returns true if it's an encoded error (Legacy vs Single\Multiple).
Error Cluster to Array of Errors.vi returns 1 or multiple errors (Single vs Multiple).
Thanks for pointing me to vi.lib. I think I will make my own error handler. Unless someone else has a good one to share or already made a vipm-package for it.
I'd put it on GIT.
I'll have to find a few minutes to polish it up to standard (it's not bad IIRC). It always takes more time that you think...
@thols wrote:
wiebe@CARYA wrote:
...
\vi.lib\MultiError\Is Encoded.vi returns true if it's an encoded error (Legacy vs Single\Multiple).
Error Cluster to Array of Errors.vi returns 1 or multiple errors (Single vs Multiple).
Thanks for pointing me to vi.lib. I think I will make my own error handler. Unless someone else has a good one to share or already made a vipm-package for it.
These VIs, very refreshing, are not password protected.
The Is Encoded VI is a subVI and all palette VIs and subVIs are open.
wiebe@CARYA wrote:
@thols wrote:
Is there a replacement for Simple Error Handler to manage this?
I've made my own.
It's not as hard as it looks. At least not if you don't use the advanced 'simple error handler' options, like custom errors.
You can reuse lots of the error handling code to 'resolve' the errors (add possible causes, etc.), the only problem is that the output string has HTML-ish tags (<b>) removed.
@thols wrote:Is there a better way to do this than to write my own error handler?
I was waiting for an opportunity to do a presentation on this. I'd share my VI (which isn't that much of a deal). I guess I could share anyway, now that guest presentations on NIWeek are off.
It's more of a starting point then a final solution.
The multiple errors have been great for me. Apart from the lack of documentation and a dialog, it added a lot to my applications with very, very little effort.
Necroposting this thread since I just learned about the newer JSON style multiple error codes and this thread is basically the only thing that comes up on Google regarding multiple errors per wire.
@wiebe, did you ever post your code or perhaps make that presentation you mentioned? If so I'd love to see it. I haven't started implementing this yet but it looks incredibly useful.
