Overhaul error system for easier programatic interogation

[den3tsou]

There is a scenario that we would like to know the error specific to geometry, for example invalid geometry. However, there is no way to identify whether or not the errors come from geometry specific problem. for instance, with the struct below. I am unable to tell the errors from json.Unmarshal() is geom specific.

type Place struct {
    name string `json:"name"`
    geometry geom.AnyGeometry `json:"geometry"`
}

Due to this reason, we have to work around this by separate structs to

type Place struct{
    name string `json:"name"`
    geometry geom.AnyGeometry `json:"-"`
}

type ValidGeom struct {
    geometry geom.AnyGeometry `json:"geometry"` 
}
var place Place
if err := json.Unmarshal(data, &place); err != nil {
    return fmt.Errorf("name is invalid: %s", err)
}

var validGeom ValidGeom
if err := json.Unmarshal(data, &validGeom); err != nil {
    return fmt.Errorf("geom is invalid: %s", err)
}

[peterstace]

In general, the error system needs an overhaul.

Right now, all of the errors returned are opaque, and would require string matching in order to programmatically handle various errors in different ways.

But really, there are a few different classes of errors:

• Parsing errors (WKTs and WKBs). E.g. when parsing POINT((0.5 1.0)).
• Validation errors for geometry construction, e.g. polygon has a non closed ring.
• Not Implemented style errors (for Intersection, Intersects, and Equals -- and maybe more going forward). The intention is that the usage of this would be eliminated once everything is implemented.
• Errors that get passed through from outside the library. E.g. when marshalling, the io.Writer could return an error.

This ticket can be for a wider error overhaul. The following Gophercon 2019 talk gives an interesting way to construct errors that can be easily interrogated, it may be worth designing something similar to that. https://www.youtube.com/watch?v=4WIhhzTTd0Y

[peterstace]

Closed via #308