Graphhopper: Internal Server Error when sending POST request to /route without specifying points

[easbar]

curl -X POST -H "Content-type: application/json" -d "{}" http://localhost:8989/route

Error handling a request: 17a5bee0823f74d0
java.lang.IndexOutOfBoundsException: Index 0 out of bounds for length 0

[michaz]

Ah, this has nothing to do with custom exception handling and mediatypes for once, but is a simple error.

In GH core, there's a check that checks that enough points are there, and it returns a GHResponse with an error (as is the convention there..) And it works when there are no CHs. (Like in the tests.)

But when there are CHs, we get an ArrayIndexOutOfBoundsException from somewhere where CH preconditions are checked.

[michaz]

~I think we agree now that all validation should be in the web service, and if the library must do it again, then it can, but.. the web service should only pass valid requests to the library.~

~Maybe we should slowly start @Valid ating the GHRequest. Without changing anything in the core for now.~

[michaz]

... with the slight complication that validation annotations don't work with Mixins of course, because Mixins are Jackson and this is Hibernate >:-(

[michaz]

Or maybe (for RouteResource) indeed remove all the exceptions in the resource, and make sure all the exceptions in the core are thrown from the right place and as IllegalArgumentException.

No idea.

[easbar]

I would check something like "point list may not be empty" in GraphHopper#route, because they need to be checked also when using GraphHopper without the resource. For GET we already do this in the resource and I would just move it into the GraphHopper class, see #1996.

[easbar]

In GH core, there's a check that checks that enough points are there, and it returns a GHResponse with an error (as is the convention there..) And it works when there are no CHs. (Like in the tests.)

Ugh its even more complicated than that: CH has to to be disabled and then there is this checkNonChMaxWaypointDistance check which causes the error, but this check only really runs if the max non ch distance is not set to default (Integer.MAX)...

[easbar]

I fixed this in #2010