You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by "Thilo Goetz (JIRA)" <ui...@incubator.apache.org> on 2007/03/08 18:02:24 UTC
[jira] Commented: (UIMA-340) Provide a standard way to distinguish
"Document Error" from "Engine Error"
[ https://issues.apache.org/jira/browse/UIMA-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12479359 ]
Thilo Goetz commented on UIMA-340:
----------------------------------
Nice to see this from somebody else, I've been telling this to anybody who'd listen for the past couple of years ;-)
The clean way to do this would be for the process method to have a return value. That way, the annotator could easily say that it can't handle a certain document. To my mind, this kind of flow control should not be done via exceptions.
> Provide a standard way to distinguish "Document Error" from "Engine Error"
> --------------------------------------------------------------------------
>
> Key: UIMA-340
> URL: https://issues.apache.org/jira/browse/UIMA-340
> Project: UIMA
> Issue Type: Wish
> Components: Core Java Framework
> Reporter: Adam Lally
> Priority: Minor
>
> A user requests that UIMA allows an analysis component to specify, when it throws an exception, whether the exception is a "Document Error" (the analysis component can't process this particular document but is otherwise OK) vs. an "Engine Error" (the analysis component is in a bad state and will likely have problems processing subsequent documents too).
> Not all annotators will have such self-awareness, but for those that do it would be nice to provide a standard way to indicate the kind of failure. This would especially help if there is custom error handling logic, for example in the CPE StatusCallbackListener, that may want to take different actions in these two cases.
> There are a couple of possible approaches for doing this -
> (a) add an optional property to AnalysisEngineProcessException (maybe other exception types too), which the analysis component can set
> (b) create subclasses of AnalysisEngineProcessException (maybe other exception types too). The analysis component can throw a specialized subclass if it is knows enough to do so.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (UIMA-340) Provide a standard way to distinguish
"Document Error" from "Engine Error"
Posted by Marshall Schor <ms...@schor.com>.
Thilo Goetz (JIRA) wrote:
> [ https://issues.apache.org/jira/browse/UIMA-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12479359 ]
>
> Thilo Goetz commented on UIMA-340:
> ----------------------------------
>
> Nice to see this from somebody else, I've been telling this to anybody who'd listen for the past couple of years ;-)
>
> The clean way to do this would be for the process method to have a return value. That way, the annotator could easily say that it can't handle a certain document. To my mind, this kind of flow control should not be done via exceptions.
>
Can you give a few pros/cons to using return values versus exceptions?
-Marshall
>
>
>> Provide a standard way to distinguish "Document Error" from "Engine Error"
>> --------------------------------------------------------------------------
>>
>> Key: UIMA-340
>> URL: https://issues.apache.org/jira/browse/UIMA-340
>> Project: UIMA
>> Issue Type: Wish
>> Components: Core Java Framework
>> Reporter: Adam Lally
>> Priority: Minor
>>
>> A user requests that UIMA allows an analysis component to specify, when it throws an exception, whether the exception is a "Document Error" (the analysis component can't process this particular document but is otherwise OK) vs. an "Engine Error" (the analysis component is in a bad state and will likely have problems processing subsequent documents too).
>> Not all annotators will have such self-awareness, but for those that do it would be nice to provide a standard way to indicate the kind of failure. This would especially help if there is custom error handling logic, for example in the CPE StatusCallbackListener, that may want to take different actions in these two cases.
>> There are a couple of possible approaches for doing this -
>> (a) add an optional property to AnalysisEngineProcessException (maybe other exception types too), which the analysis component can set
>> (b) create subclasses of AnalysisEngineProcessException (maybe other exception types too). The analysis component can throw a specialized subclass if it is knows enough to do so.
>>
>
>