WCS error handling needs cleanup

[Dimitar Misev]

WCS returns bad errors for many exceptions, e.g. for a missing mandatory parameter in KVP it returns a runtime error, or wrong subsetting syntax: x(5:15) returns

<ows:ExceptionText>For input string: "5:15"</ows:ExceptionText> 

[Peter Baumann]

as a first measure, all exceptions should be thrown in a way to keep history, for a comprehensive debug output (student task?)

[Dimitar Misev]

First step is to make sure that ExceptionReport properly concatenates all parent exceptions, so that the history is preserved in the final message.

For example, the request

http://localhost:8080/rasdaman?service=WCS&version=2.0.1&request=GetCoverage&coverageid=rgb&subset=i(2,10)&subset=j(110.0/2)

returns

<ows:ExceptionReport version="2.0.0"
    xsd:schemaLocation="http://www.opengis.net/ows/2.0 http://schemas.opengis.net/ows/2.0/owsExceptionReport.xsd"
    xmlns:ows="http://www.opengis.net/ows/2.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema-instance" xmlns:xlink="http://www.w3.org/1999/xlink">
    <ows:Exception exceptionCode="RasdamanRequestFailed">
        <ows:ExceptionText>Error executing rasql query: Error evaluating rasdaman query: 'select csv((c) [2:10,(110.0)/(2)]) from rgb AS c where oid(c)=24065</ows:ExceptionText>
    </ows:Exception>
</ows:ExceptionReport>

which doesn't not include the additional Exception message that you see in the logs, because it's not marshalled in the ExceptionReport

Caused by: org.odmg.QueryException: Execution error 390 in line 1, column 16, near token [: Minterval dimension specifications must be either of type interval or integer.
	at rasj.odmg.RasOQLQuery.execute(RasOQLQuery.java:259)
	at petascope.util.ras.RasUtil.executeRasqlQuery(RasUtil.java:134)
	... 27 more

[Peter Baumann]

should we invest extra effort, as WCPS 1.5 is coming any day now?

[Piero Campalani]

OWS XML schema allows an unbounded sequence of exceptions in a report, although they're not meant to be nested:

  <sequence>
    <element ref="ows:Exception" maxOccurs="unbounded">
      <annotation>
        <documentation>
Unordered list of one or more Exception elements that each describes an error. These 
Exception elements shall be interpreted by clients as being independent of one another (not 
hierarchical).
        </documentation>
      </annotation>
    </element>
  </sequence>

So this is not ideal for stack traces, imho. However, inside one ows:Exception you can put several (hierarchical by order) messages:

  <element name="ExceptionText" type="string" minOccurs="0"
           maxOccurs="unbounded">
    <annotation>
      <documentation>
Ordered sequence of text strings that describe this specific exception or error. The 
contents of these strings are left open to definition by each server implementation. A 
server is strongly encouraged to include at least one ExceptionText value, to provide more 
information about the detected error than provided by the exceptionCode. When included, 
multiple ExceptionText values shall provide hierarchical information about one detected 
error, with the most significant information listed first.
      </documentation>
    </annotation>
  </element>

[Peter Baumann]

valuable insights!

[Dimitar Misev]

We don't want to stacktraces anyway in the ExceptionReport, but a list of the exception messages (all wrapped in separate Exception tags)

[Dimitar Misev]

E.g. in my example that would be

<ows:ExceptionReport version="2.0.0"
    xsd:schemaLocation="http://www.opengis.net/ows/2.0 http://schemas.opengis.net/ows/2.0/owsExceptionReport.xsd"
    xmlns:ows="http://www.opengis.net/ows/2.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema-instance" xmlns:xlink="http://www.w3.org/1999/xlink">
    <ows:Exception exceptionCode="RasdamanRequestFailed">
        <ows:ExceptionText>Error executing rasql query: Error evaluating rasdaman query: 'select csv((c) [2:10,(110.0)/(2)]) from rgb AS c where oid(c)=24065</ows:ExceptionText>
        <ows:ExceptionText>Execution error 390 in line 1, column 16, near token [: Minterval dimension specifications must be either of type interval or integer.</ows:ExceptionText>
    </ows:Exception>
</ows:ExceptionReport>

[Peter Baumann]

agreed, one for the user and the rest into the log. If an error message should be less than understandable then we need to work on transforming the exceptions when they ripple up. I remember from the past that there is plenty of room for improving, but admittedly it's a tricky and tedious work. Just some thoughts.

[Dimitar Misev]

Fixed the report in #730, closing this one as a duplicate.