Closed markheger closed 6 years ago
Thanks @markheger ... As best practises, I think we should establish an optional error port, rather than an error attribute. It keeps the error data a bit more separate and people do not have to parse for error attribute downstream. It also make it easier for people to handle errors in the application... consider the case that I can publish the error port data out.. and optionally launch another application to handle the error.
Optional error port is fine
I think, it is important to have the information about the error events inline and synchronous in the output stream. This is the only way to enable an correct error handling in downstream operators. E. g. if we want to enable exactly once processing, we must ensure that data tuple and the information about the occurrence of error events is synchronously carried through the processing chain. In modern Streams versions it is nearly impossible to ensure synchronous transport in separate streams due to various and dynamic threading models. Thus an error attribute (probably with an optional type) is a perfect way to achieve this. For cases where an separate error stream is an option we can support this as an optional port.
Having both is fine. Perhaps we should discuss what the error attribute and the error port should carry so we can be clear that we are talking about the same thing.
In the case of error attribute, what information will be conveyed to the attribute? In the case of error port, what information will be conveyed by that port?
If optional error attribute is present, then exceptions in Uima processing engine or serialization should not cause operator crash and the exceptions should be caught and an error message be set on an output attribute. Possible error scenario: #53