[crelf]

I presented at NI-Week 2009 on a couple of paradigms for extending the LabVIEW Error Handling Core (as inspired by all your posting here). Here are the resources from that presentation (I didn't screencapture the examples, but you should be able to see what I was talking about from the video and the code that's included):

Presentation Video Part 1: Introduction
Presentation Video Part 2: WrapNECinOO
Presentation Video Part 3: WrapOOinNEC
Presentation Video Part 4: Summary

 Presentation Slides.pdf (516.9K)
Number of downloads: 642

 Presentation Code.zip (1.01MB)
Number of downloads: 307

It's a hot topic, and I know a lot of people have strong opinions on it, so let's discuss!

[Mark Yedinak]

Having attended the presentation I can certainly say that it was an excellent discussion and a very interesting topic. Several of us continued the conversation at dinner Thursday evening.

The one aspect I wanted to say though is that whatever architecture gets chosen it should provide support for multiple errors. A good general purpose error handler should be able to see multiple error events and take the appropriate action. A prime example for this would be some system failure that is of a high priority and then a secondary error when trying to log the event. Both are certainly problems but how they are handled is completely different. With a single error the application would have to decide whether to ignore the error when logging the data or worse, override the more critical system error with the log error.

Anyway, for those who were unable to attend I highly recommend reviewing the presentation.

[crelf]

Something I'd thought about a while ago, and gb119 eloquently descrived on the LabVIEW Idea Exchange here, is the automatic conversion between the NEC and a new paradigm (ie: LVOOP Errors Class). One idea I'd had was something like the "Merge Signals" primative that is automatically inserted when you try to wire two signals into a graph:



One of the real limitations of the "NEC in OO" paradigm that was presented is backward compatibility - this might alleviate some of that pain (automatically adding a onvert to and convert from on either side of a subVI with the NEC type - while including a wire between the conversion VIs to keep the existing errors data - sort of like wiring an existing cluster to the "input cluster" input of the "bundle by name" primative):

Mark Yedinak, on 10 August 2009 - 06:46 PM, said:

Having attended the presentation I can certainly say that it was an excellent discussion and a very interesting topic. Several of us continued the conversation at dinner Thursday evening.

I wish I had have been there! I'm glad you enjoyed it and it was thought-provoking - I think it's a very interesting topic and an opportunity for us to make a real difference in an area that we all know could be better

[Mark Yedinak]

crelf, on 10 August 2009 - 06:14 PM, said:

I wish I had have been there! I'm glad you enjoyed it and it was thought-provoking - I think it's a very interesting topic and an opportunity for us to make a real difference in an area that we all know could be better

Um, I'm pretty sure that I was sitting next to you at Iron Works. I didn't think you had that much to drink already.

The one issue that I see with your proposal for the overt conversion is that it will still require lots of rework for old code. At a minimum all of the old code will need to be wrapped to do the conversion. Truthfully I am not sure what the best answer is with respect to backward compatibility but it will certainly be an issue to contend with.

[crelf]

Mark Yedinak, on 11 August 2009 - 12:53 AM, said:

Um, I'm pretty sure that I was sitting next to you at Iron Works. I didn't think you had that much to drink already.

Of course you were! I'm sooo getting my NI-Week days mixed up That was pretty damn good brisket - I sure remember that...

Mark Yedinak, on 11 August 2009 - 12:53 AM, said:

The one issue that I see with your proposal for the overt conversion is that it will still require lots of rework for old code. At a minimum all of the old code will need to be wrapped to do the conversion. Truthfully I am not sure what the best answer is with respect to backward compatibility but it will certainly be an issue to contend with.

Yep - I agree. I don't think that there's going to be a silver bullet, unless there's something funky under the hood that NI can use to make magic happen. I know it's going to be a difficult road, and we might be tempted to use the shove-everything-in-the-source-string method which, as I said in my presentation (as reminded by Aristos ) isn't necessarily a bad thing since it's already error data, but we're going to have to have multiple errors, and it's only through some magic in the new GEH that that's going to happen.

[ryank]

Mark Yedinak, on 10 August 2009 - 06:46 PM, said:

Having attended the presentation I can certainly say that it was an excellent discussion and a very interesting topic. Several of us continued the conversation at dinner Thursday evening.

The one aspect I wanted to say though is that whatever architecture gets chosen it should provide support for multiple errors. A good general purpose error handler should be able to see multiple error events and take the appropriate action. A prime example for this would be some system failure that is of a high priority and then a secondary error when trying to log the event. Both are certainly problems but how they are handled is completely different. With a single error the application would have to decide whether to ignore the error when logging the data or worse, override the more critical system error with the log error.

Anyway, for those who were unable to attend I highly recommend reviewing the presentation.

I go back and forth on this. While I'd love the ability to handle multiple errors, I'm also very concerned with performance (I do a lot of RT programming) and passing around an arbitrarily large object gets tough performance wise (not that the current string isn't already unbounded, but multiple errors would be aribtrarily larger ). There are a couple of ways you could remedy this, one would be to store a table in memory and then pass around indexes to the table (i.e. pass by ref). Another, and the one I use currently, is just to use some sort of central error handler that recieves errors through a queue or FIFO. You still have to be diligent in invoking the message to the error handler before you overwrite the error or miss a subsequent one though.

crelf, on 09 August 2009 - 09:26 PM, said:

I presented at NI-Week 2009 on a couple of paradigms for extending the LabVIEW Error Handling Core (as inspired by all your posting here). Here are the resources from that presentation:

Thanks for posting this, I unfortunately got dragged into a meeting and couldn't make the presentation, so I'm glad I at least got a chance to review the slides. One thing I'm curious about, have you done any type of comparison, performance wise, between some code implemented with this object based method and the same code with the traditional method? I've found its useful to try to characterize the performance of error handling both in terms of what it costs when there isn't an error and what it costs when there is one.

Regards,
Ryan K.
NI Systems Engineer

[Yair]

ryank, on 20 August 2009 - 06:21 PM, said:

Another, and the one I use currently, is just to use some sort of central error handler that recieves errors through a queue or FIFO. You still have to be diligent in invoking the message to the error handler before you overwrite the error or miss a subsequent one though.

The main problem I find with this approach is that sometimes you need to do something when handling the error (e.g. ask the user) in order to proceed with the process where the error occured. If the error handler is generic, this can become a problem, because the code for each process would be different (e.g. one might need to ask the user on a specific error, another might need to check an analog input and another might not need to do anything).

[ryank]

Yair, on 20 August 2009 - 05:19 PM, said:

The main problem I find with this approach is that sometimes you need to do something when handling the error (e.g. ask the user) in order to proceed with the process where the error occured. If the error handler is generic, this can become a problem, because the code for each process would be different (e.g. one might need to ask the user on a specific error, another might need to check an analog input and another might not need to do anything).

That's why I differentiate between specific error handling, and central error handling. For my solution to specific error handling, and error categorization check this:
http://zone.ni.com/d...a/epd/p/id/6253

[crelf]

ryank, on 20 August 2009 - 04:21 PM, said:

...have you done any type of comparison, performance wise, between some code implemented with this object based method and the same code with the traditional method?

Sorry you couldn't make it No, I haven't done any performance measurements on any of this code.

Yair, on 20 August 2009 - 05:19 PM, said:

The main problem I find with this approach is that sometimes you need to do something when handling the error (e.g. ask the user) in order to proceed with the process where the error occured. If the error handler is generic, this can become a problem, because the code for each process would be different (e.g. one might need to ask the user on a specific error, another might need to check an analog input and another might not need to do anything).

Maybe I don't understand the issue, but the OO in NEC paradigm is specifically designed to meet that: you dynamic dispatch in the appropriate error handler on the fly.

ryank, on 20 August 2009 - 05:27 PM, said:

That's why I differentiate between specific error handling, and central error handling.

Oh - I see where the miscommunication is - yes, I presented on the error core, not error handling. I'd like to limit the conversations in this thread to the core, although we'll need to inevitable discuss handling too, but I'd like that to be in a separate thread (feel free to start one and link to it from here).

[ryank]

crelf, on 20 August 2009 - 06:08 PM, said:

Sorry you couldn't make it No, I haven't done any performance measurements on any of this code.


Maybe I don't understand the issue, but the OO in NEC paradigm is specifically designed to meet that: you dynamic dispatch in the appropriate error handler on the fly.


Oh - I see where the miscommunication is - yes, I presented on the error core, not error handling. I'd like to limit the conversations in this thread to the core, although we'll need to inevitable discuss handling too, but I'd like that to be in a separate thread (feel free to start one and link to it from here).

Fair enough, although I do think you need to consider error handling when you think about the requirements of the core. For example, if you've got a good centralized handler and an easy way to get things to it, the core doesn't necessarily need the capability for multiple errors.

[Yair]

crelf, on 20 August 2009 - 08:08 PM, said:

Maybe I don't understand the issue, but the OO in NEC paradigm is specifically designed to meet that

Correct, but I was replying to Ryan's post, and presumably he wasn't refering to using your newly presented paradigm (or even something like Stephen's example from way back) in his past applications. I'm not actually sure that the SEH library would work as is for something like this. I haven't looked at it yet, but a quick glance at the article seems to indicate that it only supports specific actions, whereas I'm thinking of more complex code in addition to the standard error handling code. An OO local (or maybe even central) handler would work for that.

[ryank]

Yair, on 20 August 2009 - 07:10 PM, said:

Correct, but I was replying to Ryan's post, and presumably he wasn't refering to using your newly presented paradigm (or even something like Stephen's example from way back) in his past applications. I'm not actually sure that the SEH library would work as is for something like this. I haven't looked at it yet, but a quick glance at the article seems to indicate that it only supports specific actions, whereas I'm thinking of more complex code in addition to the standard error handling code. An OO local (or maybe even central) handler would work for that.

Sorry, didn't mean to side-track things . At one point I did have the ability to call a VI as one of the actions to take in the SEH, but I took it out because I didn't want to deal with all of the potential implications.

[crelf]

ryank, on 20 August 2009 - 07:03 PM, said:

Fair enough, although I do think you need to consider error handling when you think about the requirements of the core.

I totally agree, and when we get to that then we need to create the new thread an cross reference between them.

[Tim_S]

crelf, on 09 August 2009 - 04:26 PM, said:

I presented at NI-Week 2009 on a couple of paradigms for extending the LabVIEW Error Handling Core (as inspired by all your posting here). Here are the resources from that presentation:

Thanks for posting this here; I wasn't able to make it to NI week , so I'm glad for this post. I'm still processing this and where it can be of value, but here's my thoughts...

I don't use the native error handling (specifically I use the cluster, but not the VIs) as the information provided in the dialog is not useful to the end user, or I need the code to continue running as the system must respond to the error (e.g., stop the test based on a fault occurring).

The first case only has one error, so I create a message and use the 1, 2 or 3 button dialog to display what I need to the operator. I like the idea of having the option to include pictures, links to online manuals, etc., available in the error message dialog. This makes the OO in NEC an interesting concept, though I could accomplish the same thing with a subVI. I can't say I've ever had multiple errors with this type.

I handle the second case through the use of an error daemon, allowing the parallel loop display the error so the generating loop can handle the fallout. The cluster I send to the daemon is not an error cluster (especially since I'm often dealing with multiple language selection, a large, nasty beast in-and-of-itself). This would be where I handle multiple errors as there may not be an operator to click on a dialog box.


Tim

[crelf]

Tim_S, on 21 August 2009 - 06:34 PM, said:

This makes the OO in NEC an interesting concept, though I could accomplish the same thing with a subVI.

The benefit is that the way an error is handled is defined at runtime when the error is handled - so yes, you could use a subVI, but that would only be helpful if all of your errors are of the same type (or are handled in the same way).

[Tim_S]

crelf, on 21 August 2009 - 01:54 PM, said:

The benefit is that the way an error is handled is defined at runtime when the error is handled - so yes, you could use a subVI, but that would only be helpful if all of your errors are of the same type (or are handled in the same way).

This is part devil's advocate and part for my comprehension... I can see where I have errors that would be displayed differently (say, file not found versus cable not plugged in). Wouldn't I have to know what the error state when coding to select the correct object (assuming using OO)? If so, I don't see the benefit of defining at runtime.

Thinking of some of your code samples, I'm handling the error message upstream of where you would. Handling the error upstream would generate more case statements at the "top" level, so later VIs would not get executed.

Tim

[crelf]

Tim_S, on 21 August 2009 - 08:29 PM, said:

Wouldn't I have to know what the error state when coding to select the correct object (assuming using OO)?

I don't understand that sentance - can you please try exaplaining the use case in a different way? "Wouldn't I have to know what the error state..." doesn't make sense to me.

Tim_S, on 21 August 2009 - 08:29 PM, said:

Thinking of some of your code samples, I'm handling the error message upstream of where you would. Handling the error upstream would generate more case statements at the "top" level, so later VIs would not get executed.

It's not about where you put your GEH, but what the GEH can do (which, by association, is about where you put the GEH ). The G in GEH stands for "general" - the OO in NEC paradigm has a GEH that allows the action on error to be dynamically choosen based on the type of error (which is defined by the class of error object that is in the source string input of the NEC).

Tim_S, on 21 August 2009 - 08:29 PM, said:

...part devil's advocate...

Ask anyone I work with - I *love* playing devil's advocate. In fact, I'd say it's my favourite game (especially when the other players don't know that I'm doing it )

[Tim_S]

crelf, on 21 August 2009 - 04:03 PM, said:

I don't understand that sentance - can you please try exaplaining the use case in a different way? "Wouldn't I have to know what the error state..." doesn't make sense to me.

Pardon me as I take off my technician hat and put on my programmer hat...

What I was saying is that I expect a subset of errors to occur. I (currently) have to decipher these error codes to produce a meaningful message to the operator. My statement was as a technician where each error causes a different thing to look for (think state machine).

crelf, on 21 August 2009 - 04:03 PM, said:

The G in GEH stands for "general" - the OO in NEC paradigm has a GEH that allows the action on error to be dynamically choosen based on the type of error (which is defined by the class of error object that is in the source string input of the NEC).

ErrorHandling Example.vi
Here's a quick example, no OO as I'm just throwing this together. The errors coming out of the file open, write and close will always require the same type of display (in this case, a 'this is what went wrong message'). Perhaps I'm perceiving an example that doesn't lend itself to more advanced error handling.

crelf, on 21 August 2009 - 04:03 PM, said:

Ask anyone I work with - I *love* playing devil's advocate. In fact, I'd say it's my favourite game (especially when the other players don't know that I'm doing it )

Wouldn't that be: ?

Attached File(s)

•  ErrorHandling Example.vi (10.43K)
  Number of downloads: 139

[crelf]

OK, I've rendered a video of the presentation - does anyone know of a good place to upload it to? I'd prefer not to clog the LAVA server - I'd rather upload it to somewhere else and link to it from there.

[ohiofudu]

crelf, on 28 September 2009 - 02:38 PM, said:

OK, I've rendered a video of the presentation - does anyone know of a good place to upload it to? I'd prefer not to clog the LAVA server - I'd rather upload it to somewhere else and link to it from there.

Hi,
How about U-Tube??? or send to to me by post can't wait to see your face to real

Greetings from Germany.