Added events to control processing after errors

[ArieGato]

Hi,

I added some events to control the way errors can be handled. With the changes it is possible to trap all errors on one line instead of only the first one. I also added an event to trap all errors in one line. This is my first attempts to contribute to any project, so please forgive me if it doesn't meet the standards.

Cheers, Arie

[MarcosMeli]

Great !!

Let me review the changes and apply them to the library !!

Marcos

[ArieGato]

Hi Marcos,

Any chance my changes will be added to the library?

Cheers, Arie

[ArieGato]

Hi Matthias,

You have a good point concerning return values of events. I changed the EventArgs to include a boolean property. Although this doesn't change the fact that multiple subscribers can manipulate the property.

One of the main reasons for choosing this solution was backwards compatibility. As you know throwing and handling exceptions is very expensive and killing for performance when lines contain several errors. In the old situation the line is not processed further after encountering an exception and thus enhancing performance.

In what scenario would you have multiple subscribers to the same event? The ReadFieldError event is defined on the internal sealed class RecordOperation, so a consuming project will have no way of subscribing to the event. It is strictly an internal event.

What are your thoughts on this? What would be a acceptable solution for achieving the desired functionality.

Cheers, Arie

[mcavigelli]

Hello Arie

Thanks for considering my comments. I have looked into the 3 commits included in this pull request. I still like the concept of on an error stream. It must have been a whole lot of work to do this, thank you. Generally I must say the commits are to big for me to understand. They mix changes of formatting and changed behavior. I think these two aspects should be separated.

• I hadn't noticed that the event sender is internal, sorry. I thought the event would be sent outside of the library. But how is the caller notified of such an event?
• I did not find out though, why I can decide on field errors whether to continue or not, but I cannot decide on line errors. Is there a reason for that?
• There are no tests for the changed behavior. Do you think you could write them? Maybe that would answer, how the library caller is addressed of an error.
• I think the localization of errors (Resources folder) should not be part of this pull request: it's a different topic and it seems to me that it is done so far in a different way (Messages folder). What do you think?

Matthias

[MarcosMeli]

Added to the 4.0 discussion

@ArieGato Great idea about error events and handling, but we must think about a way to notify the errors.

The version 4.0 will be .Net 4.0 and forward compatible, so we can use Lambda expressions and other advanced language features. To allow better multi-threading features I was thinking in create something like a ProcessingContext object that can be used in engine operations

That object can allow us add some lambda expressions for processing, somethiing like:

https://gist.github.com/MarcosMeli/a9db0b7f11de0d072609