postgis/wms -- sql errors not reported

moving to 1.3.1

This should expose you more to the WMS spec - read up on how one should handle errors, and to how error handling is generally done in geoserver.

I believe the spec lets users define how they want their errors, they can be returned as an image or as xml. Make sure we honor their request, and that we report back properly.

You'll also have to look in to the response strategies - this may only work well with the buffer ones - speed will likely screw up since the error occurs when streaming out. Though I could be wrong, if we're writing to the image buffer perhaps we can recover?

Hum... this is tricky. The streaming renderer does not break at the first error, but tries to merrily go on... that's why you don't see errors.
Should we have a behaviour like break on first error instead?
We may have projection errors and the like...

There's actually some advantages to not breaking with the first error, as there are operations that just mess up one feature and not all of them. One thing we could consider is break if it's the very first feature, since that's likely to be an error with the sql statement, and errors that come later are probably just a feature? But I'd say for now we should just move this issue later, it's fine if people have to dig in to the logs a bit...

Well, I was thinking about it, and it occurred to me we could classify errors in the client code, using error listeners that are already there, and stop
whenever there's an IO error. Usually error related to single features are related to transfromations, or styles application, and so on.
Too bad there is no clear way to push to the client both the resulting image and a list of errors...

Moving to 1.5.0-M0 since I don't have any better 1.5 version numbers.

Thinking about it, we need to know when an error occurrs before the first feature of every layer, since queries are performed layer by layer during rendering. I'm inclined to see a better error hierarchy as better solution, so I'd say, leave this to gt2 2.3.x and geoserver 1.5.0.

I'm opening an issue on gt2 to discuss this better with Jesse.

Hum, logging was not there because of the Log4jFormatter issues, not logging the exceptions, that has been recently solved.
Not sure about wheter to report the error to the user thought... Maybe we could introduce an error limit and fail map generator after maxErrors errors, where maxErrors is configurable...

With Gabriel exception listener GS now breaks with every error that's not a reprojection one, and reports the failure (as seen with the many people having issues with malformed rings recently). So I guess this one is fixed.

Mass closing all issues that have been in "resolved" state for 2 months or more without any feedback or update