Error case in Event case structure.

[Mythilt]

Generally speaking part of an event loop will have an error wire as part of the loop.  It would be nice to have as part of the <This VI> or <Dynamic> event cases an Error Event case for a specified error wire.  This event would be triggered when an active error wire entered the event case, rather than when an error occurs, allowing the program to handle the error elsewhere if desired.  It would appear something like below.

[AristosQueue (NI)]

I take it you believe that putting a Case Structure around the Event Structure is too much effort and/or too much space?

I strongly dislike mixing the functionality of structure nodes. I think it makes our language much less readable -- it becomes harder to assert any given behavior is true the more special behaviors a given structure (or regular node) has. This blending of event handling with sequential data flow is something I would generally oppose, both personally and in my role in R&D as someone who tries to make the best possible G language. It is not a strong opposition. If there were enough support, I'd go along with it, but I'd have to see a lot of people thinking it is a good idea.

[Mythilt]

No, in fact I usually have a case structure around the Event Structure (though it is more an aspect of the state machine, a case for initialization, a case for user interaction, a case for exiting the loop, not for error handling).  My thoughts were more in line with the idea that an Error is an event, and that by adding it to the event structure it would be handled more in line with that concept.  Also by implimenting it that way, it could be considered a sort of try...catch implimentation.  It was just an idea, and I can agree with opposition to mix functionality, but as I mentioned above, I tend to consider errors to be an event.

[crossrulz]

Data on a wire is not an event.  Though, you could use a User Event with an error data type.  Then you can handle your error with an error event case.

[AristosQueue (NI)]

> Data on a wire is not an event. 

My opinion exactly.

To me, there is little difference between arguing for an error terminal and arguing for any other case selector terminal. Why not a ? for a Boolean? Or a non-zero integer? Or a non-empty string?

[Hugin.]

Putting philosophical questions aside, I would probably find this functionality useful. I sometimes find myself abusing the Timeout event to catch errors. But then again, I could just as easily put a case structure around the event loop. The advantage of the "Error event" would be to reduce the number of nested structures.

[AristosQueue (NI)]

Hugin: Please tell me you do not actually use that pattern for error handling. If you do, you should be aware that there's a rather severe problem with the code you've written. I took the time to create this VI snippet to show you the problem.

Basically, the timeout event only fires if the queue is empty. If there are pending events, they go ahead and get handled. So if you have a backlog of events and one event sets the error, that error won't be handled until the other events are dealt with, potentially messing up your run time state significantly depending upon the reason for the error... consider back-to-back events "Put Uranium Chamber Into Safe Mode", "Signal Staff Safe To Enter"... if there's an error in that first event, you probably don't want to proceed with the next event without handling that error!

The correct place to put the error handling is either inside the particular frame that caused the error or in code outside the event structure to the right of the event structure.

[Hugin.]

AristosQueue

"Hugin: Please tell me you do not actually use that pattern for error handling."

I am well aware of the potential problems of this pattern, this is why I called it abuse. But I fear that I have actually used it on a few occasions for some quick hacks

If this idea was implemented, I imagine it would be equivalent to putting a case structure around the event structure; that is, the "Error event" would jump to the front of the event queue, pre-empting any other pending events. Perhaps it would discourage the above abuse (or indeed, throwing a user event in case of an error, which gives the same problems).

But I agree that it would be mixing the functionalities of the structures. Maybe a better idea would be to put a case structure for error handling in the standard event loop templates, to educate users.

[AristosQueue (NI)]

> Maybe a better idea would be to put a case structure for error

> handling in the standard event loop templates, to educate users.

Except that I wouldn't ever educate a user that way. Errors should be handled in the frame that generated that error. If it leaves the frame, in the vast VAST majority of cases, it should do so either

a) only for logging purposes or

b) to end the event loop.

Folding the error around to the next iteration of the While Loop is generally bad programming. Why? Because a common error handler is almost always a bad idea unless every frame of your event structure can generate the same set of errors and recovery from that error is the same. Even when you have a common error handler, having that be a subVI that is called after the Event Structure in the same frame of the While Loop is more efficient (you don't have to worry with copying all the shift register data around).

I really think that this is a bad idea. It would encourage practices that I think are more harmful to good G programming than helpful.

[Hugin.]

@AristosQueue

OK, you have convinced me. I withdraw my kudo.

Hugin

[JÞB]

I'm Glad that discussion went down that road!  If you really need an event on Error.... Generate one!