Такой исключительный Go

Недавно были опубликованы черновики дизайна новой обработки ошибок в Go 2. Очень радует, что язык не стоит на одном месте — он развивается и c каждым годом хорошеет как на дрожжах.

Только вот пока Go 2 лишь виднеется на горизонте, а ждать уж очень тягостно и грустно. Посему берем дело в свои руки. Немножко кодогенерации, чуть работы с ast, и легким движением руки паники превращаются, превращаются паники… в элегантные исключения!

И сразу же хочу сделать очень важное и абсолютно серьезное заявление.
Данное решение носит исключительно развлекательный и педагогический характер.
То бишь just 4 fun. Это вообще proof-of-concept, по правде говоря. Я предупредил :)

Так что же вышло

Получилась небольшенькая такая библиотека-кодогенератор. А кодогенераторы, как всем хорошо известно, несут в себе добро и благодать. На самом деле нет, но в мире Go они довольно популярны.

Натравливаем такой кодогенератор на go-сырец. Он его парсит за помощью стандартного модуля go/ast, делает там некие нехитрые трансформации, результат пишет рядышком в файл, добавляя суффикс _jex.go. Полученные файлы для работы хотят малюсенький рантайм.

Вот таким вот незамысловатым образом мы и добавляем исключения в Go.

Пользуем

Подключаем генератор к файлу, в шапку (до package) пишем

//+build jex
//go:generate jex

Если теперь запустить команду go generate -tags jex, то будет выполнена утилитка jex. Она берет имя файла из os.Getenv("GOFILE"), кушает его, переваривает и пишет {file}_jex.go. У новорожденного файла в шапке уже //+build !jex (тег инвертирован), так что go build, а в купе с ним и остальные команды, навроде go test или go install, учитывают только новые, правильные файлы. Лепота...

Теперь дот-импортируем github.com/anjensan/jex.
Да-да, пока импорт через точку обязателен. В будущем планируется оставить точно также.

import . "github.com/anjensan/jex"

Отлично, теперь в код можно вставлять вызовы функций-заглушек TRY, THROW, EX. Код при всем этом остается синтаксически валидным, и даже компилируется в необработанном виде (только не работает), поэтому доступны автодополнения и линтеры не особо ругаются. Редакторы показали бы и документацию к этим функциям, если бы только она у них была.

Бросаем исключение

THROW(errors.New("error name"))

Ловим исключение

if TRY() {
    // некий код
} else {
    fmt.Println(EX())
}

Под капотом сгенерируется анонимная функция. А в ней defer. А в нем еще одна функция. А в ней recover… Ну там еще немного ast-магии для обработки return и defer.

И да, кстати, они поддерживаются!

Вдобавок есть особая макро-переменная ERR. Если присвоить в нее ошибку, то выкидывается исключение. Так легче вызывать функции, которые по старинке все еще возвращают error

file, ERR := os.Open(filename)

Дополнительно имеется парочка небольших утилитных пакетика ex и must, но там не о чем особо рассказывать.

Примеры

Вот пример корректного, идиоматичного кода на Go

func CopyFile(src, dst string) error {
    r, err := os.Open(src)
    if err != nil {
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }
    defer r.Close()

    w, err := os.Create(dst)
    if err != nil {
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }

    if _, err := io.Copy(w, r); err != nil {
        w.Close()
        os.Remove(dst)
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }

    if err := w.Close(); err != nil {
        os.Remove(dst)
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }
}

Этот код не так уж приятен и элегантен. Между прочим, это не только мое мнение!
Но jex поможет нам его улучшить

func CopyFile_(src, dst string) {
    defer ex.Logf("copy %s %s", src, dst)

    r, ERR := os.Open(src)
    defer r.Close()

    w, ERR := os.Create(dst)

    if TRY() {
        ERR := io.Copy(w, r)
        ERR := w.Close()
    } else {
        w.Close()
        os.Remove(dst)
        THROW()
    }
}

А вот например следующая программа

func main() {
    hex, err := ioutil.ReadAll(os.Stdin)
    if err != nil {
        log.Fatal(err)
    }

    data, err := parseHexdump(string(hex))
    if err != nil {
        log.Fatal(err)
    }

    os.Stdout.Write(data)
}

может быть переписана как

func main() {
    if TRY() {
        hex, ERR := ioutil.ReadAll(os.Stdin)
        data, ERR := parseHexdump(string(hex))
        os.Stdout.Write(data)
    } else {
        log.Fatal(EX())
    }
}

Вот ещё пример, дабы прочувствовать предложенную идею получше. Оригинальный код

func printSum(a, b string) error {
    x, err := strconv.Atoi(a)
    if err != nil {
        return err
    }
    y, err := strconv.Atoi(b)
    if err != nil {
        return err
    }
    fmt.Println("result:", x + y)
    return nil
}

может быть переписан как

func printSum_(a, b string) {
    x, ERR := strconv.Atoi(a)
    y, ERR := strconv.Atoi(b)
    fmt.Println("result:", x + y)
}

или вот даже так

func printSum_(a, b string) {
    fmt.Println("result:", must.Int_(strconv.Atoi(a)) + must.Int_(strconv.Atoi(b)))
}

Исключение

Суть простенькая структурка-обертка над экземпляром error

type exception struct {
    // оригинальная ошибка, без комментариев
    err      error
    // всякий мусор^Wотладочная информация, переменные, логи там какие
    log      []interface{}
    // вдруг мы уже обрабатывали другую ошибку, когда бросили исключение
    suppress []*exception
}

Важный момент — обычные паники не воспринимаются как исключения. Так, не являются исключениями все стандартные ошибки, вроде runtime.TypeAssertionError. Это соответствует принятым бест-практикам в Go — если у нас, скажем, nil-dereference, то мы весело и бодренько роняем весь процесс. Надежно и предсказуемо. Хотя не уверен, быть может стоит пересмотреть данный момент и таки ловить подобные ошибки. Может опционально?

А вот пример цепочки исключений

func one_() {
    THROW(errors.New("one"))
}

func two_() {
    THROW(errors.New("two")
}

func three() {
    if TRY() {
        one_()
    } else {
        two_()
    }
}

Тут мы спокойно обрабатываем исключение one, как внезапно бац… и выбрасывается исключение two. Так вот к нему в поле suppress автомагически прикрепится исходное one. Ничего не пропадет, все пойдет в логи. А посему и нету особой надобности запихивать всю цепочку ошибок прямо в текст сообщения при помощи весьма популярного паттерна fmt.Errorf("blabla: %v", err). Хотя никто, конечно, не запрещает его использовать и здесь, если уж очень хочется.

Когда забыли отловить

Ах, еще один шибко важный момент. В целях повышения читаемости имеется дополнительная проверка: если функция может выкинуть исключение, то ее имя должно оканчиваться на _. Сознательно кривое имя, которое подскажет программисту "многоуважаемый сударь, вот тут в вашей программе что-то может пойти не так, извольте проявить внимательность и усердие!"

Проверка автоматом запускается для трансформируемых файлов, плюс еще может быть запущена вручную в проекте при помощи команды jex-check. Пожалуй имеет смысл запускать ее как часть билд процесса наравне с прочими линтерами.

Отключается проверка комментарием //jex:nocheck. Это, к слову, пока единственный способ выбрасывать исключения из анонимной функции.

Конечно это не панацея от всех проблем. Чекер пропустит вот такое

func bad_() {
    THROW(errors.New("ups")) 
}
func worse() {
    f := bad_
    f()
}

С другой стороны, это не сильно хуже стандартной проверки на err declared and not used, которую ну очень легко обойти

func worse() {
    a, err := foo()
    if err != nil {
        return err
    }
    b, err := bar()
    // забыли проверку, а все типо ok... go vet, доколе?
}

В общем, сей вопрос скорее философский, что же лучше делать, когда забыли обработать ошибку — втихую ее проигнорировать, или выкинуть панику… Кстати, лучших результатов проверки можно было бы достигнуть, внедряя поддержку исключений в компилятор, но это сильно выходит за рамки данной статьи.

Некоторые могут сказать, что, хоть это и замечательное решение, но уже исключениями не является, поскольку сейчас исключения означают вполне конкретную реализацию. Ну там потому, что к исключениям не прикрепляются стектрейсы, или есть отдельный линтер для проверки имен функций, или что функция может заканчиваться на _ но при этом не выбрасывать исключений, или нету прямой поддержки в синтаксисе, или что это на самом деле паники, а паники не исключения вовсе, потому что гладиолус… Споры могут быть столь же жаркими, сколь бесполезными и бесцельными. Посему оставлю их за бортом статьи, а описанное решение продолжу невозбранно обзывать "исключениями".

По поводу стектрейсов

Часто разработчики в целях упрощения отладки приклепляют стектрейс к кастомным имплементациям error. Есть даже несколько популярных библиотек для этого. Но, к счастью, с исключениями для этого не нужно никаких дополнительных действий благодаря одной интересной особенности Go — при панике блоки defer выполняются в стековом контектсе того кода, который панику выбросил. Поэтому тут

func foo_() {
    THROW(errors.New("ups"))
}

func bar() {
    if TRY() {
        foo_()
    } else {
        debug.PrintStack()
    }
}

распечатается полноценный стектрейс, пускай и чуть многословный (имена файлов вырезал)

  runtime/debug.Stack
  runtime/debug.PrintStack
  main.bar.func2
  github.com/anjensan/jex/runtime.TryCatch.func1
  panic
  main.foo_
  main.bar.func1
  github.com/anjensan/jex/runtime.TryCatch
  main.bar
  main.main

Не помешает еще сделать свой хелпер для форматирования/печати стектрейса с учетом суррогатных функций, скрывая их для читаемости. Думаю неплохая идея, записал в .

А можно захватить стек и прикрепить его к исключению при помощи ex.Log(). Потом такое исключение дозволено передавать в другую гороутину — стректрейсы не теряются.

func foobar_() {
    e := make(chan error, 1)
    go func() {
        defer close(e)
        if TRY() {
            checkZero_()
        } else {
            EX().Log(debug.Stack()) // прикрепляем стектрейс
            e <- EX().Wrap()        // оборачиваем исключение в ошибку
        }
    }()
    ex.Must_(<-e)  // разворачиваем и, быть может, перевыбрасываем
}

К сожалению

Эх… конечно, куда лучше выглядело бы что-то такое

    try {
        throw io.EOF, "some comment"
    } catch e {
        fmt.Printf("exception: %v", e)
    }

Но увы и ах, синтаксис у Go нерасширяемый.
[задумчиво] Хотя, наверное, это все же к лучшему...

В любом случае, приходится извращаться. Одной из альтернативных идей было сделать

    TRY; {
        THROW(io.EOF, "some comment")
    }; CATCH; {
        fmt.Printf("exception: %v", EX)
    }

Но такой код выглядит стремновато после go fmt. А еще компилятор ругается, когда видит return в обоих ветках. С if-TRY такой проблемы нет.

Было бы еще круто заменить макрос ERR на функцию MUST (лучше просто must). Дабы писать

    return MUST(strconv.Atoi(a)) + MUST(strconv.Atoi(b))

В принципе это таки реализуемо, можно при анализе ast выводить тип выражений, для всех вариантов типов сгенерировать простую функцию-обертку, вроде тех, что объявлены в пакете must, а потом подменять MUST на имя соответствующей суррогатной функции. Это не совсем тривиально, но совершенно возможно… Только вот редакторы/иде не смогут понимать такой код. Ведь сигнатура функции-заглушки MUST не выражаема в рамках системы типов Go. А поэтому никакого автокомплита.

Под капотом

Во все обработанные файлы добавляется новый импорт

    import _jex "github.com/anjensan/jex/runtime"

Вызов THROW заменяется на panic(_jex.NewException(...)). Также происходит замена EX() на имя локальной переменной, в которой лежит выловленное исключение.

А вот if TRY() {..} else {..} обрабатывается чуть посложнее. Сначала происходит специальная обработка для всех return и defer. Потом обработанные ветки if-а помещаются в анонимные функции. И потом эти функции передаются в _jex.TryCatch(..). Вот такое

func test(a int) (int, string) {
    fmt.Println("before")
    if TRY() {
        if a == 0 {
            THROW(errors.New("a == 0"))
        }
        defer fmt.Printf("a = %dn", a)
        return a + 1, "ok"
    } else {
        fmt.Println("fail")
    }
    return 0, "hmm"
}

превращается примерно в такое (я убрал комментарии //line):

func test(a int) (_jex_r0 int, _jex_r1 string) {
    var _jex_ret bool

    fmt.Println("before")

    var _jex_md2502 _jex.MultiDefer
    defer _jex_md2502.Run()

    _jex.TryCatch(func() {
        if a == 0 {
            panic(_jex.NewException(errors.New("a == 0")))
        }
        {
            _f, _p0, _p1 := fmt.Printf, "a = %dn", a
            _jex_md2502.Defer(func() { _f(_p0, _p1) })
        }
        _jex_ret, _jex_r0, _jex_r1 = true, a+1, "ok"
        return
    }, func(_jex_ex _jex.Exception) {
        defer _jex.Suppress(_jex_ex)
        fmt.Println("fail")
    })
    if _jex_ret {
        return
    }
    return 0, "hmm"
}

Много, не красиво, но работает. Ладно, не все и не всегда. Например, не получится сделать defer-recover внутри TRY, поскольку вызов функции оборачивается в дополнительную лямбду.

Также при выводе ast дерева указана опция "сохранить комментарии". Так что, по идее, go/printer должен их распечатать… Что он честно и делает, правда очень и очень криво =) Примеры приводить не буду, просто криво. В принципе, такая проблемка вполне решаема, если тщательно указать позиции для всех ast-узлов (сейчас они пустые), но это точно не входит в список необходимых вещей для прототипа.

Пробуем

Из любопытства написал небольшой бенчмарк.

Имеем деревянную реализацию qsort'а, которая в нагрузку проверяет наличие дубликатов. Нашли — ошибка. Одна версия просто пробрасывает через return err, другая уточняет ошибку вызовом fmt.Errorf. И еще одна использует исключения. Сортируем слайсы разного размера, либо вовсе без дубликатов (ошибки нет, слайс сортируется полностью), либо с одним повтором (сортировка обрывается примерно на полпути, видно по таймингам).

~ > cat /proc/cpuinfo | grep 'model name' | head -1
model name    : Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz
~ > go version 
go version go1.11 linux/amd64
~ > go test -bench=. github.com/anjensan/jex/demo
goos: linux
goarch: amd64
pkg: github.com/anjensan/jex/demo
BenchmarkNoErrors/_____10/exception-8             10000000           236 ns/op
BenchmarkNoErrors/_____10/return_err-8             5000000           255 ns/op
BenchmarkNoErrors/_____10/fmt.errorf-8             5000000           287 ns/op
BenchmarkNoErrors/____100/exception-8               500000          3119 ns/op
BenchmarkNoErrors/____100/return_err-8              500000          3194 ns/op
BenchmarkNoErrors/____100/fmt.errorf-8              500000          3533 ns/op
BenchmarkNoErrors/___1000/exception-8                30000         42356 ns/op
BenchmarkNoErrors/___1000/return_err-8               30000         42204 ns/op
BenchmarkNoErrors/___1000/fmt.errorf-8               30000         44465 ns/op
BenchmarkNoErrors/__10000/exception-8                 3000        525864 ns/op
BenchmarkNoErrors/__10000/return_err-8                3000        524781 ns/op
BenchmarkNoErrors/__10000/fmt.errorf-8                3000        561256 ns/op
BenchmarkNoErrors/_100000/exception-8                  200       6309181 ns/op
BenchmarkNoErrors/_100000/return_err-8                 200       6335135 ns/op
BenchmarkNoErrors/_100000/fmt.errorf-8                 200       6687197 ns/op
BenchmarkNoErrors/1000000/exception-8                   20      76274341 ns/op
BenchmarkNoErrors/1000000/return_err-8                  20      77806506 ns/op
BenchmarkNoErrors/1000000/fmt.errorf-8                  20      78019041 ns/op
BenchmarkOneError/_____10/exception-8              2000000           712 ns/op
BenchmarkOneError/_____10/return_err-8             5000000           268 ns/op
BenchmarkOneError/_____10/fmt.errorf-8             2000000           799 ns/op
BenchmarkOneError/____100/exception-8               500000          2296 ns/op
BenchmarkOneError/____100/return_err-8             1000000          1809 ns/op
BenchmarkOneError/____100/fmt.errorf-8              500000          3529 ns/op
BenchmarkOneError/___1000/exception-8               100000         21168 ns/op
BenchmarkOneError/___1000/return_err-8              100000         20747 ns/op
BenchmarkOneError/___1000/fmt.errorf-8               50000         24560 ns/op
BenchmarkOneError/__10000/exception-8                10000        242077 ns/op
BenchmarkOneError/__10000/return_err-8                5000        242376 ns/op
BenchmarkOneError/__10000/fmt.errorf-8                5000        251043 ns/op
BenchmarkOneError/_100000/exception-8                  500       2753692 ns/op
BenchmarkOneError/_100000/return_err-8                 500       2824116 ns/op
BenchmarkOneError/_100000/fmt.errorf-8                 500       2845701 ns/op
BenchmarkOneError/1000000/exception-8                   50      33452819 ns/op
BenchmarkOneError/1000000/return_err-8                  50      33374000 ns/op
BenchmarkOneError/1000000/fmt.errorf-8                  50      33705994 ns/op
PASS
ok      github.com/anjensan/jex/demo    64.008s

Если ошибка так и не брошена (код стабилен и железобетонен), то варант с пробросом исключения примерно сопоставим с return err и fmt.Errorf. Иногда чуточку быстрее. А вот ежели ошибку выбросили, то исключения уходят на второе место. Но все сильно зависит от соотношения "полезная работа / ошибки" и глубины стека. Для малых слайсов return err идет в отрыв, для средних и больших исключения уже равняются с ручным пробросом.

Короче, если ошибки возникают крайне редко — исключения могут код даже немного ускорить. Если как у всех, то будет примерно так-на-так. А вот если очень часто… то медленные исключения — далеко не самая важная проблема, из-за которой стоит переживать.

В качестве теста пробно мигрировал реальную гошную библиотеку на исключения.

    default:
        THROW(fmt.Errorf("unsupported type %T", value))

func rpcParams2XML(rpc interface{}) (string, error) {
    var err error
    buffer := "<params>"
    for i := 0; i < reflect.ValueOf(rpc).Elem().NumField(); i++ {
        var xml string
        buffer += "<param>"
        xml, err = rpc2XML(reflect.ValueOf(rpc).Elem().Field(i).Interface())
        buffer += xml
        buffer += "</param>"
    }
    buffer += "</params>"
    return buffer, err
}

func rpcParams2XML_(rpc interface{}) string {
    buffer := "<params>"
    for i := 0; i < reflect.ValueOf(rpc).Elem().NumField(); i++ {
        buffer += "<param>"
        buffer += rpc2XML_(reflect.ValueOf(rpc).Elem().Field(i).Interface())
        buffer += "</param>"
    }
    buffer += "</params>"
    return buffer
}

xmlstr, _ = rpcResponse2XML(response)

xmlstr = rpcResponse2XML_(response)

func DecodeClientResponse(r io.Reader, reply interface{}) error {
    rawxml, err := ioutil.ReadAll(r)
    if err != nil {
        return FaultSystemError
    }
    return xml2RPC(string(rawxml), reply)
}

func DecodeClientResponse_(r io.Reader, reply interface{}) {
    var rawxml []byte
    if TRY() {
        rawxml, ERR = ioutil.ReadAll(r)
    } else {
        THROW(FaultSystemError)
    }
    xml2RPC_(string(rawxml), reply)
}

func errorReporter(t testing.TB) func(error) {
    return func(e error) {
        t.Log(string(debug.Stack()))
        t.Fatal(e)
    }
}

func TestRPC2XMLConverter_(t *testing.T) {
    defer ex.Catch(errorReporter(t))
    // ...
    xml := rpcRequest2XML_("Some.Method", req)
}

func fault2XML(fault Fault) string {
    buffer := "<methodResponse><fault>"
    xml, _ := rpc2XML(fault)
    buffer += xml
    buffer += "</fault></methodResponse>"
    return buffer
}

func fault2XML(fault Fault) string {
    buffer := "<methodResponse><fault>"
    if TRY() {
        buffer += rpc2XML_(fault)
    } else {
        fmt.Printf("ERR: %v", EX())
        buffer += "<nil/>"
    }
    buffer += "</fault></methodResponse>"
    return buffer
}

По моим личным ощущениям, с ошибками легче вернуть "полуготовый" результат.
Например, наполовину сконструированный респонс. С исключениями посложнее, поскольку функция либо возвращает успешный результат, либо вообще ничего не возвращает. Эдакая атомарность. С другой стороны, исключения труднее проигнорировать или потерять первопричину при цепочке исключений. Ведь нужно еще специально постараться это сделать. С ошибками же такое происходит легко и непринужденно.

Вместо заключения

При написании данной статьи ни один гофер не пострадал.

За фотографию гофера-алкоголика спасибо http://migranov.ru

Не смог выбрать между хабами "Программирование" и "Ненормальное программирование".
Весьма сложный выбор, добавил в оба.

Автор: anjensan

Источник