Needs more error types

[raspi]

Currently this library is untranslatable to other languages due to having just error strings. So please add lot of error types and/or error enums to the error types so that errors.Is() can be utilized.

This can be also be generic issue for error handling discussion in end users perspective.

Should errors be something like

type Errcode int

const(
  Unknown Errcode = iota
  NoDot 
  NoColon 
  NoZone 
)

type ParseError struct {
  Family uint8 // 4 or 6
  Errcode Errcode
}

or

type ErrIPv6NoZone error
type ErrIPv4NoDot error

[Matt Layher]

Currently this library is untranslatable to other languages due to having just error strings.

What exactly are you trying to do? This library contains some pretty Go-specific tricks and such.

I'm not sure It's a good idea to add exported API and codes for every possible error when a lot of these boil down to basic things like "invalid user input". Can you explain your use case?

[Ben Hoyt]

@mdlayher I suspect with "untranslatable to other languages" he's referring to translating error text in a UI to other human languages, not translating the library to another programming language.

[raspi]

Yes, exactly. If the lib spits out an error that can help the end user I'd like to have specific error types which can be iterated and fed to some i18n library. For example golang.org/x/text/language and golang.org/x/text/message/catalog is the upcoming official internalization library for Go. If you only get generic error you might need to do some horrible regex parsing of the error string or write your own IP address parser before you fed it to this parser which is kind of dumb. If the goal of this library was to add better errors it should also go full way of actually providing many error types so that they can be translated to multiple languages.