История изменений

Именно для таких случаев придумали паники.

Давай начнём вот с чего. Где бывает безплатный сыр? Есть основания подозревать, что маркетологи учат не совсем тому, чему надо. Дальше, как падают? os.Exit(1). Паника - это не совсем падение, до падения оно обработает все defer-ы. Где гарантия, что наш баг не введёт эти defer-ы в ступор? Программа может не смочь упасть, в зависимости от бага. Значит, обработки баги паникой - это неверный подход, ненадёжный.

Отсюда очень простой вывод (смотри, мои руки перед тобой, я нигде не мухлюю). Если надо падать, то паника не подходит.

Дальнейшее я описал чуть выше по теме. Есть категории серьёзности ошибки (например, падение программы, падение обработчика одного запроса к сервису, предупреждение в лог), и есть способы их обработки. Что err != nil, что паника в вычислительном отношении абсолютно одинаковы. У тебя есть какая-то НЁХ. В одном случае это значение с ни к чему не обязывающим интерфейсом err, а в другом - это ни к чему не обязывающее значение, возвращённоё из recover.

Случай паники сводится к случаю возврата err примерно так:

// было
func f1 () (res int, err error) {
 return 0, errors.New("Беда")
}

func main() {
 res, err = f1()
}

// стало
func f2 () (res int) {
 panic(errors.New("Беда"))
}

res, err = func() (res int, err error) {
 defer func() { err = recover() }
 res = f2() 
 return
} ()

Если я ничего не путаю. И в обратную сторону тоже верно - панику можно выразить через return. Т.е. эти механизмы с вычислительной точки зрения тождественны, но требуют разного количества слов в разных ситуациях. То, что один из этих механизмов якобы нужно использовать «при обычных ошибка», а второй - «при необычных» - в этом и есть маркетинг. На самом деле серьёзность ошибки не так связана с тем, какой механизм нужно применять. Фатальная ошибка - это всегда только os.exit, а нефатальная может быть и err, и panic.

Именно для таких случаев придумали паники.

Давай начнём вот с чего. Где бывает безплатный сыр? Есть основания подозревать, что маркетологи учат не совсем тому, чему надо. Дальше, как падают? os.Exit(1). Паника - это не совсем падение, до падения оно обработает все defer-ы. Где гарантия, что наш баг не введёт эти defer-ы в ступор? Программа может не смочь упасть, в зависимости от бага. Значит, обработки баги паникой - это неверный подход, ненадёжный.

Отсюда очень простой вывод (смотри, мои руки перед тобой, я нигде не мухлюю). Если надо падать, то паника не подходит.

Дальнейшее я описал чуть выше по теме. Есть категории серьёзности ошибки (например, падение программы, падение обработчика одного запроса к сервису, предупреждение в лог), и есть способы их обработки. Что err != nil, что паника в вычислительном отношении абсолютно одинаковы. У тебя есть какая-то НЁХ. В одном случае это значение с ни к чему не обязывающим интерфейсом err, а в другом - это ни к чему не обязывающее значение, возвращённоё из recover.

Случай паники сводится к случаю возврата err примерно так:

// было
func f1 () (res int, err error) {
 return 0, errors.New("Беда")
}

func main() {
 res, err = f1()
}

// стало
func f2 () (res int) {
 panic(errors.New("Беда"))
}

res, err = func() (res int, err error) {
 defer func() { err = recover() }
 res = f2() 
 return
}

Если я ничего не путаю. И в обратную сторону тоже верно - панику можно выразить через return. Т.е. эти механизмы с вычислительной точки зрения тождественны, но требуют разного количества слов в разных ситуациях. То, что один из этих механизмов якобы нужно использовать «при обычных ошибка», а второй - «при необычных» - в этом и есть маркетинг. На самом деле серьёзность ошибки не так связана с тем, какой механизм нужно применять. Фатальная ошибка - это всегда только os.exit, а нефатальная может быть и err, и panic.

Именно для таких случаев придумали паники.

Давай начнём вот с чего. Где бывает безплатный сыр? Есть основания подозревать, что маркетологи учат не совсем тому, чему надо. Дальше, как падают? os.Exit(1). Паника - это не совсем падение, до падения оно обработает все defer-ы. Где гарантия, что наш баг не введёт эти defer-ы в ступор? Программа может не смочь упасть, в зависимости от бага.

Отсюда очень простой вывод (смотри, мои руки перед тобой, я нигде не мухлюю). Если надо падать, то паника не подходит.

Дальнейшее я описал чуть выше по теме. Есть категории серьёзности ошибки (например, падение программы, падение обработчика одного запроса к сервису, предупреждение в лог), и есть способы их обработки. Что err != nil, что паника в вычислительном отношении абсолютно одинаковы. У тебя есть какая-то НЁХ. В одном случае это значение с ни к чему не обязывающим интерфейсом err, а в другом - это ни к чему не обязывающее значение, возвращённоё из recover.

Случай паники сводится к случаю возврата err примерно так:

// было
func f1 () (res int, err error) {
 return 0, errors.New("Беда")
}

func main() {
 res, err = f1()
}

// стало
func f2 () (res int) {
 panic(errors.New("Беда"))
}

res, err = func() (res int, err error) {
 defer func() { err = recover() }
 res = f2() 
 return
}

Если я ничего не путаю. И в обратную сторону тоже верно - панику можно выразить через return. Т.е. эти механизмы с вычислительной точки зрения тождественны, но требуют разного количества слов в разных ситуациях. То, что один из этих механизмов якобы нужно использовать «при обычных ошибка», а второй - «при необычных» - в этом и есть маркетинг. На самом деле серьёзность ошибки не так связана с тем, какой механизм нужно применять. Фатальная ошибка - это всегда только os.exit, а нефатальная может быть и err, и panic.

Именно для таких случаев придумали паники.

Давай начнём вот с чего. Где бывает безплатный сыр? Есть основания подозревать, что маркетологи учат не совсем тому, чему надо. Дальше, как падают? os.Exit(1). Паника - это не совсем падение, до падения оно обработает все defer-ы. Где гарантия, что наш баг не введёт эти defer-ы в ступор? Программа может не смочь упасть, в зависимости от бага.

Отсюда очень простой вывод (смотри, мои руки перед тобой, я нигде не мухлюю). Если надо падать, то паника не подходит.

Дальнейшее я описал чуть выше по теме. Есть категории серьёзности ошибки (например, падение программы, падение обработчика одного запроса к сервису, предупреждение в лог), и есть способы их обработки. Что err != nil, что паника в вычислительном отношении абсолютно одинаковы. У тебя есть какая-то НЁХ. В одном случае это значение с ни к чему не обязывающим интерфейсом err, а в другом - это ни к чему не обязывающее значение, возвращённоё из recover.

Случай паники сводится к случаю возврата err примерно так:

// было
func f1 () (res int, err error) {
 return 0, errors.New("Беда")
}

func main() {
 res, err = f1()
}

// стало
func f2 () (res int) {
 panic(errors.New("Беда"))
}

res, err = func() (res int, err error) {
 defer func() { err = recover() }
 res = f2() 
 return
}

Если я ничего не путаю. И в обратную сторону тоже верно - панику можно выразить через return. Т.е. эти механизмы с вычислительной точки зрения тождественны, но требуют разного количества слов в разных ситуациях. То, что один из этих механизмов якобы нужно использовать «при обычных ошибка», а второй - «при необычных» - в этом и есть маркетинг. }