Custom automatic error handling callback

[JeffreyH]

I often have code in my apps where some error-out nodes are not wired, simply because the errors are generally not of interest to me or the error wiring would clutter up my block diagram. Typically this happens a lot in UI handling code where a lot of property nodes are used. For these parts I would rely on the automatic error handling for debugging purposes. One of the drawbacks of this method is that program execution is suspended when the automatic error handler kicks in. Even worse if this happens for code that is in a loop. You're only option then would be to abort the app, which e.g. is no good for your reference-based objects, etc.

I would love to have the ability to just specify my own 'Automatic Error Handler', enabling me to decide what to do with the unhandled errors. Just logging them is what first comes to mind, but maybe also do some special stuff depending on the type of error, just like a 'normal' error handler. I want to be in control!

Added values of this is that your application then has a catch-all error handler which enables you to at least log every error that occurs, even if not wired through. (Everyone forgets to wire some error-out that they actually did want to wire one time or another don't they? ;-))

Ofcourse the proposed setting in the image would ideally also be available programmatically by application property nodes.

[Daklu]

I would support the idea if the functionality were restricted to the dev environment and not part of a built application. There's value in logging errors that aren't explicitly propagated or cleared during development, and occasionally I get stuck in a perpetual error dialog loop that I can't break out of. It's rather annoying.

I'm not on board with building an unhandled error callback into the runtime engine. Magical calls to vis that aren't on the block diagram violates every concept of data flow in Labview.

I haven't decided on the best way to define the callback. A setting in the Labview options makes more sense if the callback is viewed as an IDE debugging tool. A project specific setting makes more sense if the callback is viewed as a general error handler for the entire application.

Neither of them (easily) allow for advanced use cases, such as providing configuration inputs to the callback that allow you to alter its behavior without creating many copies with minor differences. For that you'd need to have a RegisterUnhandledErrorCallback prim on the block diagram, which doesn't make much sense if it only works in the IDE.

The whole error in/out/path needs to be improved so that we don;t have 20%+ of the code just in stringing errors.

In my experience most moderately complex apps have anywhere from 10-50% of the code dedicated to managing errors. 20% is not out of line.

but I would want it to be something that could turn around and do something intelligent with it like "for each unwired error out, wire that as an error in to every downstream node, just don't make me wire the error wires manually" or "log the error to a file and then merge all logged errors into the nearest error out FP terminal leading out of this VI".

Aren't these features more appropriate for a solution using scripting?

But a simple "log the error some how and then swallow it without giving it to downstream code" that replaces the current Auto Error Dialog just seems like a bad idea to me.

I don't understand why this is a bad idea in the context of Jeffrey's original idea of this being a debugging tool. Logging the error gives the same information as the built-in error handler, it just does it without getting the user stuck in an unbreakable UI loop. Even if the custom callback is used in built applications, logging the error and swallowing it doesn't change the behavior of the rest of the application. As far as I know unwired errors in the runtime engine are swallowed without doing anything anyway, so I don't see how this is any worse.

I *do* think it is better to write components so they explicitly handle as many of their own errors as possible. I also think centralized error handling causes more problems than it solves. (Which is partly why I don't support this functionality in the RTE.) But overriding the functionality of a default debugging tool in the IDE doesn't seem inherently bad to me.

[Darin.K]

I simply wish there was a filter event which could stand between the error and the dialog.

[SteenSchmidt]

My 2 cents:

1) Errors definetely shouldn't be left unhandled at runtime. In my view that'd definetely be a bigger problem the larger the application. For instance I see a lot of property and invoke nodes with unwired error terminals. Excuse: "They never spew any errors anyway, my app is fully debugged by release". What happens next is that some joker calls that code on Real-Time and half of your property and invoke nodes fail. The original programmer didn't forsee that. No error handling equals big debugging pain followed by "Oh my God! Let me find that developer and hang him from a tree...". Same with prioritizing errors (or handling them on the spot they occur) - if you don't do it (i.e. don't think hard about every and each error out terminal on your BD) then you'll get bit at some point.

Anyways...

2) What we could use is some sort of overloadable automatic error handler in the IDE. One alternative idea would be to open up that error dialog (make it a public VI) so we can modify it, like it's possible to modify the icon editor for instance. I for one would very much like to see much more customizability in the IDE; VI callbacks defined for IDE events and that sort. I can literally think of hundreds of places in the dev environment where I'd like to stick in some of my own code to give me more power when I develop and debug. Not for runtime, but to improve the dev tool. Open that up and we could implement half of the most asked for ideas in this IE ourselves, thus freeing up NI resources.

/Steen

[Daklu]

I can literally think of hundreds of places in the dev environment where I'd like to stick in some of my own code to give me more power when I develop and debug. Not for runtime, but to improve the dev tool. Open that up and we could implement half of the most asked for ideas in this IE ourselves, thus freeing up NI resources.

Agreed.  This was specifically discussed at the US summit after party.  (I use the term "party" loosely.  It was really the ad-hoc round table summarized in this document on the CLA community site.  (i.e. You must be a CLA to view it.))

-----

I decided to kudo the idea, conditional on it not being included in the runtime engine.

[AristosQueue (NI)]

Ravensfan wrote:

> I don't see where the idea was was tied to being a part of the appbuilder.  Only

> that it be something that could be defined in the project.  The functionality could

> be tested out while the project was still in the development environment.

Sorry... that was a leap of mine... the picture showed Tools >> Options, which is a horrible idea, and I didn't take the time to complete all the dots that I saw in my head. Let me restate...

Tools >> Options is a horrible idea. It means that an app would behave differently based on which machine it is loaded on, exactly the problem that exists with auto error handling today. If I design an app to rely upon my error handler, it darn well better stay working when loaded on someone else's machine. Likewise, applying it after the fact in AppBuilder is a bad idea, for similar reasons, only now it behaves different on my user's machine than on my machine. Applying it in the Project file is a bad idea as a particular library or VI may be written to use a particular error handler. It needs to be bound in as something that is fundamentally part of the code, which means it has to be specified at either a library or VI level. How to make that work? No idea, but that's a restriction I consider to be non-negotiable for making this at all viable.

[_Y_]

Sorry to say so, but such a solution could be a nightmare.

Just take such a scenario. You are invited to a customer for a couple of days to add a small feature to an existing LabVIEW project. But… the project uses the proposed overriding of error handling. You add a code but cannot debug it properly because the errors are treated in a “smart” way. You disable the future and get a rain of errors from the old code.

Treatment of errors must be point-specific. Of course, some error outputs are treated in the same way through the whole program. However, such outputs must not be dumped by default. Use something like this:

Such small error-terminating icons do not take much place in BD but clearly indicate which errors are processed. If you want a “harder” link to the project, use Conditional Disable Structure instead of the Global Variable. There is a lot of room here to create reliable code.

[Nate_Moehring]

http://www.themoehrings.com/index.php/2010/12/labview-exceptions-a-paradigm-shift-to-error-handling-...

[avogadro5]

Fresh off my Nth debugging journey that ended at an unwired error terminal (not my code!), I marvel at how tied up this rather simple (and popular!) ask got in demanding a perfect solution. Can't we get anything to pick up these unwired errors in RTE?

I would rather be able to opt into crashing into something like the access violation dialog than what we have now which is nothing.

Edit: I find the "you must always wire your errors" concept extremely burdensome: other languages do you the valuable service of crashing anytime you don't handle your exceptions