Не без паники в Go

[Cobolorum]

Ну вот Go добрался до энтерпрайза. Когда nj казавшаяся гениальной конструкцией
varResult, errCode = func()
разбилась о реальности разработки – что надо не только обрабатывать varResult на месте, но и еще обрабатывать на месте errCode. Ход гениален, но вот алгоритм то у нас «однопоточный» (имеется ввиду листинг программы). Но люди помнящие Basic очень хорошо помнят что значит обрабатывать ошибку в месте ее возникновения.
А потом придет еще пушистый зверек когда какой ни будь умник захочет сделать errCode не целочисленным. И выяснится что динамическое типизирование ой как сложно поддерживать в промышленных объемах. И понесётся и понесется…

[gudvinr]

Почему в стандартных библиотеках для константных ошибок используется переменная, создаваемая через errors.New() а не, например, переопределение типа строки?
В таком случае переопределить значение будет невозможно даже случайно.

package errors

type Error string

func (e Error) Error() string {
    return string(e)
}

//
const ErrFileNotFound errors.Error = "file not found"

Допустим, в стандартных библиотеках этого нельзя сделать из-за того, что это может сломать обратную совместимость для некоторого кода.
Но в примерах и многих библиотеках такой подход тоже не используется по каким-то причинам.

[justwack]

Возможно не до конца понял вопрос, но что касается errors.New(). Он возвращает указатель на структуру с закрытым полем типа строка.
https://golang.org/src/errors/errors.go
Соответственно мы сравниваем указатели, а не строки, со всеми вытекающими от сюда.
play

func main() {
    if io.EOF == errors.New("EOF"){
        fmt.Printf("case 1")
    }
    if errors.New("EOF") == errors.New("EOF"){
        fmt.Printf("case 2")
    }
}

Например, ошибки из разных пакетов не будет равны, да же если у них одно содержание.

[ainar-g]

Дейв Чейни как раз рекомендовал такой подход в своей статье. Я в своих проектах стараюсь использовать именно такой подход.