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.

[vitoi]

Anythign to make error handling easier and better is a step in the right direction. The whole error in/out/path needs to be improved so that we don;t have 20%+ of the code just in stringing errors. Kudos.

[M_Peeker]

I kudo this idea, but I would rather see a solution where the callback is defined in the project, as I would expect to have different error catching behaviour in different applications. Also, this would propagate to built applications and distributed code.

[crossrulz]

Boo.  Auto handling erors.  Boo.

You should be handling all of your errors in some way shape or form.  Then you won't have to worry about the Automatic Error Handler.

[crelf]

I'm with M_Peeker - make it projectified.

[JeffreyH]

---

@M_Peeker: Agreed. I would prefer to have both. Be able to have our own callbacks for all LV installs (we would install it with our standard in-house vips), but overridable in the project.

@crossrulz: As an architect I preserve the right to decide not to wire errors. 😉 I explained my use cases where I think it's Boo to have to wire all errors of everything, just to catch some stuff at debug time.

[AristosQueue (NI)]

I don't know whether I favor this idea or not, but making it something that you add as part of appbuilder seems really bad. If it changes the behavior of my code, I would want it to be something I set in the dev environment so I can actually test its behavior as part of my application. Otherwise it turns into something that never gets checked in development and is used only in release and is hard to debug if something goes wrong.

In terms of "define my own auto error handler", I'm ok with something that hooks unwired error out terminals, 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". Both of those are hard to define code-wise. 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 use Auto Error a lot during development when I'm still moving functions around, but for finished code, I'm with crossrulz. I want to define how those errors should propagate. Where I split the difference between JeffreyH and crossrulz is that I don't want to have to do the wiring, but I want the wiring to be defined by me.

[JeffreyH]

@AristosQueue: I'd go for the kudo if I were you. 😉 It's optional, no changed behaviour, just new optional behaviour for imho a perfectly valid use case. Just another step in trusting us programmers a little bit more with the powers of LabVIEW.

Ofcourse I see the potential of mis-use by (novice) programmers, but that doesn't weigh up to the potential it gives us.

As for my own use case, I use a logger/handler for errors in all my apps which would enable me to at least always log those unhandled errors and optionally handle them. Ofcourse I would like LabVIEW to provide me with some relevant infos (like e.g. callchain) as parameters to the callback so it will be easy to trace the error back to the process/loop it occurred in.

[AristosQueue (NI)]

I don't see it as a problem for novice programmers. I see it as a problem in large scale applications. Novices generally don't have issues with it. It's an intermediate and advanced problem. Has nothing to do with trust.

To clarify further: my hesitation is that I see it as a waste of time for R&D to build a feature I won't use unless that feature can actually express the type of handling that I would want to express in my VIs. Since I cannot propose a way to have that happen, I'll hold off on the kudos. Should someone propose a way for this plugin VI to implement the real handling that I would like it to express, then I would be on board with the idea.

> As for my own use case, I use a logger/handler for errors in all my apps

> which would enable me to at least always log those unhandled errors

> and optionally handle them.

Define "handle." Handling for me requires some way to tell the downstream operations "do not execute because there was an upstream error (possibly translating the error code to a new error code along the way)" and/or a way to say "retry the operation that just emitted the error". Just logging is not handling, IMHO.

[RavensFan]

AristosQueue wrote:

I don't know whether I favor this idea or not, but making it something that you add as part of appbuilder seems really bad.

---

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.

[SamoraJ]

I second the "define in project, valid in both built app and dev environment"- Notion. On the essential discussion, I think it's perhaps a case of "le mieux est l'ennemi du bien". So I gave it a kudo 🙂