🧱 Что там с ошибками в Go?
Ошибки в го настолько хороши, насколько ужасны. Отсутствие какого-то синтаксического сахара вынуждает разработчика писать кучу шаблонного кода. Это бесит абсолютно всех.
Проблема не нова и, естественно, известна разработчикам языка.
С нетерпением ждём, что же придумают и сделают во второй версии языка.
Пойдём и посмотрим в issue языка, что там пишут по поводу обработки ошибок. У нас, всё-таки, опен сорс.
Начнём с 40432: резюме по основным решениям.
Check/handle подход, на который я ссылался в одном из постов, был отменён из-за возможной путаницы между handle и defer. На его основе была выдвинута новая идея, которая, на данный момент, имеет больше всего шансов на появление в ожидаемой версии.
Идея в том, чтобы добавить для переменных catch-id (синтаксически, это обычное имя переменной, чем-то выделяющееся, например, символом # в начале имени). После одного или нескольких таких определений, следует блок catch по этому самому id, который обрабатывает ошибку (это может быть любой тип, не обязательно реализующий интерфейс ошибки) если она не пустая. Один блок catch может обработать несколько прежде полученных в один идентификатор ошибок.
Выглядеть это может следующим образом
func (db *Db) GetX(data []byte) (int, error) {
n, #return := db.name() // специальное зарезервированное имя для ошибки, которая вернётся из функции
f, #err := os.Open(n) // если файл не найден, возникнет ошибка, которая будет обработана ниже в блоке catch
defer f.Close()
_, #err = f.Seek(42, io.SeekStart)
l, #err := f.Read(data)
#return = db.process(data)
catch err error { // обработка всех #err ошибок
if !os.IsNotExist(err) { log.Fatal(err) }
log.Println(n, "not found; proceding")
}
#return = db.index(data) // если catch не завершил выполнение программы, продолжаем работу
return l, nil
}
Подход мне кажется не очень привычным и немного запутанным. Хотя так всегда относишься к чему-то новому. Думаю, это всяк лучше того, что мы имеем сейчас. Преимуществом подхода отмечают сходтво с блоком try-catch без блока try.
Есть много нерешенных вопросов касательно этого подхода, подробнее о котором вы можете почитать здесь.
Ошибки в го настолько хороши, насколько ужасны. Отсутствие какого-то синтаксического сахара вынуждает разработчика писать кучу шаблонного кода. Это бесит абсолютно всех.
Проблема не нова и, естественно, известна разработчикам языка.
С нетерпением ждём, что же придумают и сделают во второй версии языка.
Пойдём и посмотрим в issue языка, что там пишут по поводу обработки ошибок. У нас, всё-таки, опен сорс.
Начнём с 40432: резюме по основным решениям.
Check/handle подход, на который я ссылался в одном из постов, был отменён из-за возможной путаницы между handle и defer. На его основе была выдвинута новая идея, которая, на данный момент, имеет больше всего шансов на появление в ожидаемой версии.
Идея в том, чтобы добавить для переменных catch-id (синтаксически, это обычное имя переменной, чем-то выделяющееся, например, символом # в начале имени). После одного или нескольких таких определений, следует блок catch по этому самому id, который обрабатывает ошибку (это может быть любой тип, не обязательно реализующий интерфейс ошибки) если она не пустая. Один блок catch может обработать несколько прежде полученных в один идентификатор ошибок.
Выглядеть это может следующим образом
func (db *Db) GetX(data []byte) (int, error) {
n, #return := db.name() // специальное зарезервированное имя для ошибки, которая вернётся из функции
f, #err := os.Open(n) // если файл не найден, возникнет ошибка, которая будет обработана ниже в блоке catch
defer f.Close()
_, #err = f.Seek(42, io.SeekStart)
l, #err := f.Read(data)
#return = db.process(data)
catch err error { // обработка всех #err ошибок
if !os.IsNotExist(err) { log.Fatal(err) }
log.Println(n, "not found; proceding")
}
#return = db.index(data) // если catch не завершил выполнение программы, продолжаем работу
return l, nil
}
Подход мне кажется не очень привычным и немного запутанным. Хотя так всегда относишься к чему-то новому. Думаю, это всяк лучше того, что мы имеем сейчас. Преимуществом подхода отмечают сходтво с блоком try-catch без блока try.
Есть много нерешенных вопросов касательно этого подхода, подробнее о котором вы можете почитать здесь.