Комментарии 4
varResult, errCode = func()
разбилась о реальности разработки – что надо не только обрабатывать varResult на месте, но и еще обрабатывать на месте errCode. Ход гениален, но вот алгоритм то у нас «однопоточный» (имеется ввиду листинг программы). Но люди помнящие Basic очень хорошо помнят что значит обрабатывать ошибку в месте ее возникновения.
А потом придет еще пушистый зверек когда какой ни будь умник захочет сделать errCode не целочисленным. И выяснится что динамическое типизирование ой как сложно поддерживать в промышленных объемах. И понесётся и понесется…
Почему в стандартных библиотеках для константных ошибок используется переменная, создаваемая через errors.New() а не, например, переопределение типа строки?
В таком случае переопределить значение будет невозможно даже случайно.
package errors
type Error string
func (e Error) Error() string {
return string(e)
}
//
const ErrFileNotFound errors.Error = "file not found"Допустим, в стандартных библиотеках этого нельзя сделать из-за того, что это может сломать обратную совместимость для некоторого кода.
Но в примерах и многих библиотеках такой подход тоже не используется по каким-то причинам.
Возможно не до конца понял вопрос, но что касается 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")
}
}Например, ошибки из разных пакетов не будет равны, да же если у них одно содержание.
Не без паники в Go