Object-oriented error handling

[candidus]

Hi folks,

 

I recently thought much about error handling. Here is my current approach. The idea is simple: There is a base class, ErrorInfo.lvclass, that is flattened to string and wrapped in the source field of an ordinary error cluster. Child classes of ErrorInfo.lvclass can provide any error properties you need. The example contains a class ExtendedErrorInfo.lvclass that has two properties, severity and timestamp.

Some details are inspired by posts here on LAVA.

 

Any comments appreciated :-)

 

candidus

 

ErrorInfo-20130624.zip

[Aristos Queue]

I posted something like this a few years ago...

http://lavag.org/topic/5047-prototype-replacement-for-error-llb-second-attempt/

 

I'm not sure why the attachments are missing -- seems they've been deleted from LAVA. I've worked on this off and on for a few years. Never gotten enough impetus to publish it into LV -- something always takes priority. I've actually got a version that is pretty advanced that I've been polishing lately. Maybe I'll pull it together in the next couple months to show off.

[Jeannius]

I posted something like this a few years ago...

http://lavag.org/topic/5047-prototype-replacement-for-error-llb-second-attempt/

 

I'm not sure why the attachments are missing -- seems they've been deleted from LAVA. I've worked on this off and on for a few years. Never gotten enough impetus to publish it into LV -- something always takes priority. I've actually got a version that is pretty advanced that I've been polishing lately. Maybe I'll pull it together in the next couple months to show off.

Have you had a chance to publish the OO error handling?

[Aristos Queue]

Have you had a chance to publish the OO error handling?

Not for lack of trying, but no, I have not succeeded. The problem comes down to the number of people who have *ahem* made deep calls into what should have been private VIs of the General Error Handler (they weren't in the palettes for a reason, people... ok, I know that's never been a barrier, but it is really a problem for trying to improve code when the entry points aren't bottlenecked). Any attempt to refactor generally runs into problems. And it HAS to be a refactor, not a deprecate and add a new function. The two times I've worked with real code to do this, we've realized that all modules in the system must be using the same error system or nothing works, and that means that the language level error system has to be replaced. 

 

What all of that means is that I'm having to refactor on the assumption that just about every VI in the existing hierarchy is a *valid entry point* into the new error system, and that requires a lot more code than I would otherwise have, but we want anyone who does just use the main entry points (the 99% case) to not have code bloat (indeed, a big part of my refactoring actually brings the code size down from current). So... what all of that means is that I have to have a lot of running room to make the system work.

 

There's a couple of other barriers within NI -- systems that chose not to support certain parts of VI Server, which means no part of the core libraries can ever use those features, which means I have to either convince someone to finish out every target with a full VI Server or get my refactoring to work without them. 

 

The long and short of it is this is not a small project by any stretch of the imagination and I'm having to line up a bunch of forces across NI to make it work along with a fairly large block of my own time. I am not confident I'll ever actually manage to do it, but I continue to try.