Advanced Error Cluster with more intuitive handling

[Norbert_B]

There was already a suggestion to improve the error cluster (here). I want to go some steps further in comparison to this idea.

Part 1: Information in the "advanced error cluster":

New elements would be "severity" and "error occurred at time".

Part 2: Behavior of the "advanced error cluster":

I think the best approach for the new error cluster would be to have it like the Dynamic Data Type, which was introduced with LV Express (7.0).

a) Compatibility to the "old error cluster":

If you wire the advanced error cluster to an old one, it would automatically create a "From Advanced Error Cluster"/"To Advanced Error Cluster". This would enable working with both clusters in parallel to keep downward compatibility.

Sure, "From Advanced Error Cluster" would remove the newly added information from the error wire. This is some caveat/downside when working with "old" functions.

b) Connecting a source of an advanced error cluster wire to an existing wire of the type would create a Merge Errors automatically. Wiring additional (advanced) error clusters on the input side of this Merge Errors would increase the number of inputs accordingly.

c) If two or more inputs of the Merge Errors function would carry an error information, the output would be a single advanced error cluster with the error information of the error input containing the highest severity.

Part 3: Possible new features for "advanced error cluster":

Esp. severity could enable good "default" functionality which could be enabled/disabled in the LV settings. Something coming into mind is:

a) Log Error: All errors are logged in a preconfigured error log file when they occur.

b) Log and Discard Low Severity: Errors which occur with Low severity are automatically logged into a preconfigured error log file and then discarded (removed from the wire).

Part 4: Other suggestion already made in regard to Error Handling:

Specific Error Handler

Object Orientated Error Handler

Feel free to add comments in order to create an "comprehensive list of error handling strategies" in order to pick the most promising for future LV features.

[smercurio_fc]

I don't like the idea of making the severity an enum. Your list of severity levels may be different from mine. 

For comparison/alternate idea, the error cluster I use in the error handling routines I wrote (which are compatible with the existing error cluster) looks like this:

I assume this new error cluster would still employ the silly convention of warnings being the status = False and the error code being non-zero? (I just love bringing this up all the time. It's one of my pet peeves, so don't take it too seriously.)

[tst]

The new error "cluster" should definitely be a class, to allow for extensibility.

In any case, I don't think the idea exchange is a good place to discuss this. Its interface is extremely unsuitable for such a discussion. The LAVA thread you linked to is a valid place for such a discussion.

In any case, a new error handling framework should probably also ship with some additional tools for error handling (such as templates, loggers, examples, etc.).

[Intaris]

Classes or leave it as it is please.....

[Darren]

Any idea that has received less than 2 kudos within 2 years after posting will be automatically declined.