Skip to content
This repository has been archived by the owner on May 25, 2023. It is now read-only.

Needs more error types #118

Open
raspi opened this issue Jan 10, 2021 · 3 comments
Open

Needs more error types #118

raspi opened this issue Jan 10, 2021 · 3 comments

Comments

@raspi
Copy link

raspi commented Jan 10, 2021

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
@mdlayher
Copy link
Member

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?

@benhoyt
Copy link

benhoyt commented Mar 10, 2021

@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
Copy link
Author

raspi commented Mar 11, 2021

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants