LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Error handling using ”Retain all errors”

Solved!
Go to solution

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.

thols_3-1618394713377.png

 

 

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.

Certified LabVIEW Architect
0 Kudos
Message 1 of 12
(2,465 Views)
Solution
Accepted by thols

@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.

Message 2 of 12
(2,461 Views)

@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.

Certified LabVIEW Architect
0 Kudos
Message 3 of 12
(2,458 Views)

@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).

0 Kudos
Message 4 of 12
(2,456 Views)

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.

Certified LabVIEW Architect
0 Kudos
Message 5 of 12
(2,455 Views)

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.

Certified LabVIEW Architect
0 Kudos
Message 6 of 12
(2,452 Views)

@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?

0 Kudos
Message 7 of 12
(2,445 Views)

@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...

0 Kudos
Message 8 of 12
(2,443 Views)

@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.  

Message 9 of 12
(2,427 Views)

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.

0 Kudos
Message 10 of 12
(1,871 Views)