Provide clear error message when WCPS query exceeds coverage bounds

[Dirk Daems]

When a user forgets to specify CRS:1 in the query below, a vague error is returned: “Runtime error while processing request: For input string: i_i[0]”.

for c in (mean_summer_airtemp)
  return condense +
  over $x x(500:600),
       $y y(500:600)
  where (max(c[x($x:$x),y($y:$y)]) < 100)
  using c[x($x),y($y)]

[abeccati]

Thanks Dirk for your report, would you please also provide the query that generates no error, this will help ticket consistency and speed up investigation.

Meanwhile tentatively assigning for further evaluation.

[Dirk Daems]

The WCPS query that works:

for c in (mean_summer_airtemp)
  return condense +
  over $x x(500:600),
       $y y(500:600)
  where (max(c[x:"CRS:1"($x:$x),y:"CRS:1"($y:$y)]) < 100)
  using c[x:"CRS:1"($x),y:"CRS:1"($y)]

[swingit]

The fix is simple "per se". The easiest way to fix that was to catch the java.lang.NumberFormat exception and wrap it into a WCPSException containing all necessary information describing the error.

Something like that (except for necessary additions to utils.WCPSConstants)

            // Fixing bug #394 [author Swing:It]
            // axisLo = Integer.parseInt(axis.getLoCellCoord());
            // axisHi = Integer.parseInt(axis.getHiCellCoord());
            // Start fix
            boolean phase = false;
            try {
                 log.trace("  " + WCPSConstants.MSG_AXIS + ": Getting coordinates.");
                 axisLo = Integer.parseInt(axis.getLoCellCoord());
                 .... omissis ...
                 axisHi = Integer.parseInt(axis.getHiCellCoord());
            } catch (NumberFormatException e) {
                    String errmsg = ... omissis... ;
                    log.error(errmsg + ": " + axis.getAxisName());
                    throw new WCPSException(errmsg + ": " + axis.getAxisName()
                            + "[" + e.getMessage() + "]");
            }
            // End fix #394

Unfortunately, the exception thrown there is first caught and rethrown twice in CoverageExpr.java
where fortunately the information containt survives and it is finally caught in ScalarExpr.java:85
where thaks to the following catch clause

        // NumericScalarExprType
        if (child == null) {
            if (NumericScalarExpr.NODE_NAMES.contains(n)) {
                try {
                  ...
                } catch (WCPSException e) {
                    child = null;
                }
            }
        }

every information is lost.

The solution is now twofold:

• either fixing this code to make the e.message survive
• or producing a different Exception which cannot neither inherit from WCPSException (this I don't like)

We'll looking for a solution to this.

[swingit]

A new patch, including a test, was uploaded to patch manager few days ago.

[Dirk Daems]

Now I don't get an errormessage anymore when executing the query listed above. Is this expected behaviour as the default CRS is EPSG:4326?
Actually this ticket was meant for collecting several WCPS error handling improvements. Closing it gives the wrong impression that WCPS error handling has improved. That's why I suggest to change the ticket summary.