[ 
https://issues.apache.org/jira/browse/JENA-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13398645#comment-13398645
 ] 

Rob Vesse commented on JENA-236:
--------------------------------

Actually this error handling is already in place so I'm failing to see what 
exactly the issue is here.

If SILENT is on for the SERVICE clause then we will ignore the error and move 
on, if it is not then we throw an error and query processing stops.  This is 
completely in line with the SPARQL specification so what exactly is the 
behavior you were hoping to achieve?

Adding SILENT to your queries causes a continue on error which AFAICT is what 
you want or are you wanting to preserve the results retrieved up to the point 
of the error and make that a configurable non-standard behavior?
                
> Allow Service XML Parsing error to cancel the query on a per query basis
> ------------------------------------------------------------------------
>
>                 Key: JENA-236
>                 URL: https://issues.apache.org/jira/browse/JENA-236
>             Project: Apache Jena
>          Issue Type: Improvement
>          Components: ARQ
>    Affects Versions: ARQ 2.9.0
>         Environment: All
>            Reporter: Claude Warren
>            Assignee: Rob Vesse
>              Labels: features
>         Attachments: JENA-236-1.txt
>
>
> Currently an XML parsing error may occur on a hasNext() call on a Sparql 
> service query.  The result is that the entire query (not just the service 
> call) fails.
> The goal of this improvement is to capture the XML parsing error and return 
> false for the hasNext().  The result being that data errors will be silently 
> ignored.  This should be done on a per endpoint basis.  Perhaps as an 
> onParseErrorCancel flag.
> I think there is an interplay of several flags in this request:
> 1) SILENT service parameter.  If silent is true should this also be true by 
> default? (I think not, but perhaps a system setting to make that the case)
> 2) cancelAllowDrain.  If the error occurs should the cancel flag be raised? 
> (I think not, but again perhaps a per service call flag to enable this)
> 3) JENA-93 discusses changing cancelAllowDrain to be a per endpoint setting.  
> If that is the case it may apply here as well.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to