История изменений
Исправление kaldeon, (текущая версия) :
ошибка аккуратно уронила нужный контекст (например текущий запрос)
Для меня «аккуратно уронить» обозначает сделать так, чтобы вызывающему было хорошо. Вызываемая функция может сообщить что пошло не так (“parsing $url as HTML: $err”), сделать удобное определение ошибки (по значению, типу, поведению). Ничто не мешает это повторить в исключениях, но в исключениях мы не ожидаем мгновенной реакции на ошибку, это чья-то чужая проблема, поэтому нет стимула напрягаться.
То, что ошибка должна обработаться где-то выше — это естественно. Ненормально заранее не думать об этом.
оставив систему в консистентном состоянии
ACID? Было бы, наверное, хорошо, если весь мир был ACID, но в реальности зоопарк. И здесь обработка ошибок может оказать огромную услугу: освобождение неиспользованного хранилища, очистка грязных глобальных данных, отмена начатых незаконченных операций, обработка неполных данных, сохранение сложных вычислений или ввода пользователя.
И этого практически всегда хватает.
«Хватает» в том смысле, что в штате тысяча программистов, готовых разгребать падающие системы хоть каждый день, лишь бы деньги платили?
Хотелось бы долгосрочных улучшений.
Конечно бывают ситуации, когда действительно важно показать пользователю правильное сообщение об ошибке
В идеале всегда. Стек-трейс – это инструмент даже не для программиста, а для разработчика. А пользователем может быть кто угодно, в том числе разработчик. Обработка ошибок позволяет это обеспечить, следуя общему правилу «если f(x) упала, укажи f и x в ошибке».
когда важно обработать ошибку нетривиальным образом и тд и тп, но такие ситуации редки
Они станут ещё реже, если о них вообще не думать. Когда, в сотый раз дополняя ошибку, будешь писать “server failed to respond”, в голову может прийти идея сделать повторный запрос. Или продолжить выполнение с изменённым конфигом. Или проигнорировать и быть уверенным в том, что игнорирование точно уместно (скажем, удаление временных ресурсов), а не кто-то до тебя зачем-то оставил пустой catch-блок.
А в коде безумное множество того, что может выдать ошибку в теории, но на практике не выдаст.
Ещё как выдаст, просто этот момент ещё не наступил. Как раз когда падает самая надёжная операция, больше всего хочется узнать причину.
универсальной обработки для этой [редкой] ошибки хватит за глаза
Стек-трейсы содержат иерархию вызовов и точку отказа. Ни то ни другое не указывает однозначно на природу ошибки и не содержит дополнительного контекста. Можно получить из канала io.Reader, в котором внезапно окажется сетевой ресурс, и ошибку придётся дебажить.
И пытаться обрабатывать все ошибки - верный способ написать уйму кода, который никто никогда не протестирует и который как раз совсем не факт, что в реальности сработает адекватно.
Примерно то же самое можно сказать про защиту от дурака (она же defensive programming). Тем не менее, польза ни у кого не вызывает сомнений.
Что такое errors? Это This repository was archived?
Да. Не знаю что лучше выбрать в 2026. Но вообще никто не запрещает хоть самому велосипед написать. То, что в стандартной библиотеке есть fmt.Errorf и errors — это аргумент, но не причина отказываться от сторонних решений, как никто не отказывается от сторонних HTTP-роутеров.
Исправление kaldeon, :
ошибка аккуратно уронила нужный контекст (например текущий запрос)
Для меня «аккуратно уронить» обозначает сделать так, чтобы вызывающему было хорошо. Вызываемая функция может сообщить что пошло не так (“parsing $url as HTML: $err”), сделать удобное определение ошибки (по значению, типу, поведению). Ничто не мешает это повторить в исключениях, но в исключениях мы не ожидаем мгновенной реакции на ошибку, это чья-то чужая проблема, поэтому нет стимула напрягаться.
То, что ошибка должна обработаться где-то выше — это естественно. Ненормально заранее не думать об этом.
оставив систему в консистентном состоянии
ACID? Было бы, наверное, хорошо, если весь мир был ACID, но в реальности зоопарк. И здесь обработка ошибок может оказать огромную услугу: освобождение неиспользованного хранилища, очистка грязных глобальных данных, отмена начатых незаконченных операций, обработка неполных данных, сохранение сложных вычислений или ввода пользователя.
И этого практически всегда хватает.
«Хватает» в том смысле, что в штате тысяча программистов, готовых разгребать падающие системы хоть каждый день, лишь бы деньги платили?
Хотелось бы долгосрочных улучшений.
Конечно бывают ситуации, когда действительно важно показать пользователю правильное сообщение об ошибке
В идеале всегда. Стек-трейс – это инструмент даже не для программиста, а для разработчика. А пользователем может быть кто угодно, в том числе разработчик. Обработка ошибок позволяет это обеспечить, следуя общему правилу «если f(x) упала, укажи f и x в ошибке».
когда важно обработать ошибку нетривиальным образом и тд и тп, но такие ситуации редки
Они станут ещё реже, если о них вообще не думать. Когда, в сотый раз дополняя ошибку, будешь писать “server failed to respond”, в голову может прийти идея сделать повторный запрос. Или продолжить выполнение с изменённым конфигом. Или проигнорировать и быть уверенным в том, что игнорирование точно уместно (скажем, удаление временных ресурсов), а не кто-то до тебя зачем-то оставил пустой catch-блок.
А в коде безумное множество того, что может выдать ошибку в теории, но на практике не выдаст.
Ещё как выдаст, просто этот момент ещё не наступил. Как раз когда падает самая надёжная операция, больше всего хочется узнать причину.
универсальной обработки для этой [редкой] ошибки хватит за глаза
Стек-трейсы содержат иерархию вызовов и точку отказа. Ни то ни другое не указывает однозначно на природу ошибки и не содержит дополнительного контекста. Можно передать сетевой ресурс за интерфейсом в bufio и ошибку придётся дебажить.
И пытаться обрабатывать все ошибки - верный способ написать уйму кода, который никто никогда не протестирует и который как раз совсем не факт, что в реальности сработает адекватно.
Примерно то же самое можно сказать про защиту от дурака (она же defensive programming). Тем не менее, польза ни у кого не вызывает сомнений.
Что такое errors? Это This repository was archived?
Да. Не знаю что лучше выбрать в 2026. Но вообще никто не запрещает хоть самому велосипед написать. То, что в стандартной библиотеке есть fmt.Errorf и errors — это аргумент, но не причина отказываться от сторонних решений, как никто не отказывается от сторонних HTTP-роутеров.
Исправление kaldeon, :
ошибка аккуратно уронила нужный контекст (например текущий запрос)
Для меня «аккуратно уронить» обозначает сделать так, чтобы вызывающему было хорошо. Вызываемая функция может сообщить что пошло не так (“parsing $url as HTML: $err”), сделать удобное определение ошибки (по значению, типу, поведению). Ничто не мешает это повторить в исключениях, но в исключениях мы не ожидаем мгновенной реакции на ошибку, это чья-то чужая проблема, поэтому нет стимула напрягаться.
То, что ошибка должна обработаться где-то выше — это естественно. Ненормально заранее не думать об этом.
оставив систему в консистентном состоянии
ACID? Было бы, наверное, хорошо, если весь мир был ACID, но я лично это редко вижу. И здесь обработка ошибок может оказать огромную услугу: освобождение неиспользованного хранилища, очистка грязных глобальных данных, отмена начатых незаконченных операций, обработка неполных данных, сохранение сложных вычислений или ввода пользователя.
И этого практически всегда хватает.
«Хватает» в том смысле, что в штате тысяча программистов, готовых разгребать падающие системы хоть каждый день, лишь бы деньги платили?
Хотелось бы долгосрочных улучшений.
Конечно бывают ситуации, когда действительно важно показать пользователю правильное сообщение об ошибке
В идеале всегда. Стек-трейс – это инструмент даже не для программиста, а для разработчика. А пользователем может быть кто угодно, в том числе разработчик. Обработка ошибок позволяет это обеспечить, следуя общему правилу «если f(x) упала, укажи f и x в ошибке».
когда важно обработать ошибку нетривиальным образом и тд и тп, но такие ситуации редки
Они станут ещё реже, если о них вообще не думать. Когда, в сотый раз дополняя ошибку, будешь писать “server failed to respond”, в голову может прийти идея сделать повторный запрос. Или продолжить выполнение с изменённым конфигом. Или проигнорировать и быть уверенным в том, что игнорирование точно уместно (скажем, удаление временных ресурсов), а не кто-то до тебя зачем-то оставил пустой catch-блок.
А в коде безумное множество того, что может выдать ошибку в теории, но на практике не выдаст.
Ещё как выдаст, просто этот момент ещё не наступил. Как раз когда падает самая надёжная операция, больше всего хочется узнать причину.
универсальной обработки для этой [редкой] ошибки хватит за глаза
Стек-трейсы содержат иерархию вызовов и точку отказа. Ни то ни другое не указывает однозначно на природу ошибки и не содержит дополнительного контекста. Можно передать сетевой ресурс за интерфейсом в bufio и ошибку придётся дебажить.
И пытаться обрабатывать все ошибки - верный способ написать уйму кода, который никто никогда не протестирует и который как раз совсем не факт, что в реальности сработает адекватно.
Примерно то же самое можно сказать про защиту от дурака (она же defensive programming). Тем не менее, польза ни у кого не вызывает сомнений.
Что такое errors? Это This repository was archived?
Да. Не знаю что лучше выбрать в 2026. Но вообще никто не запрещает хоть самому велосипед написать. То, что в стандартной библиотеке есть fmt.Errorf и errors — это аргумент, но не причина отказываться от сторонних решений, как никто не отказывается от сторонних HTTP-роутеров.
Исправление kaldeon, :
ошибка аккуратно уронила нужный контекст (например текущий запрос)
Для меня «аккуратно уронить» обозначает сделать так, чтобы вызывающему было хорошо. Вызываемая функция может сообщить что пошло не так (“parsing $url as HTML: $err”), сделать удобное определение ошибки (по значению, типу, поведению). Ничто не мешает это повторить в исключениях, но в исключениях мы не ожидаем мгновенной реакции на ошибку, это чья-то другая проблема, поэтому нет стимула напрягаться.
То, что ошибка должна обработаться где-то выше — это естественно. Ненормально заранее не думать об этом.
оставив систему в консистентном состоянии
ACID? Было бы, наверное, хорошо, если весь мир был ACID, но я лично это редко вижу. И здесь обработка ошибок может оказать огромную услугу: освобождение неиспользованного хранилища, очистка грязных глобальных данных, отмена начатых незаконченных операций, обработка неполных данных, сохранение сложных вычислений или ввода пользователя.
И этого практически всегда хватает.
«Хватает» в том смысле, что в штате тысяча программистов, готовых разгребать падающие системы хоть каждый день, лишь бы деньги платили?
Хотелось бы долгосрочных улучшений.
Конечно бывают ситуации, когда действительно важно показать пользователю правильное сообщение об ошибке
В идеале всегда. Стек-трейс – это инструмент даже не для программиста, а для разработчика. А пользователем может быть кто угодно, в том числе разработчик. Обработка ошибок позволяет это обеспечить, следуя общему правилу «если f(x) упала, укажи f и x в ошибке».
когда важно обработать ошибку нетривиальным образом и тд и тп, но такие ситуации редки
Они станут ещё реже, если о них вообще не думать. Когда, в сотый раз дополняя ошибку, будешь писать “server failed to respond”, в голову может прийти идея сделать повторный запрос. Или продолжить выполнение с изменённым конфигом. Или проигнорировать и быть уверенным в том, что игнорирование точно уместно (скажем, удаление временных ресурсов), а не кто-то до тебя зачем-то оставил пустой catch-блок.
А в коде безумное множество того, что может выдать ошибку в теории, но на практике не выдаст.
Ещё как выдаст, просто этот момент ещё не наступил. Как раз когда падает самая надёжная операция, больше всего хочется узнать причину.
универсальной обработки для этой [редкой] ошибки хватит за глаза
Стек-трейсы содержат иерархию вызовов и точку отказа. Ни то ни другое не указывает однозначно на природу ошибки и не содержит дополнительного контекста. Можно передать сетевой ресурс за интерфейсом в bufio и ошибку придётся дебажить.
И пытаться обрабатывать все ошибки - верный способ написать уйму кода, который никто никогда не протестирует и который как раз совсем не факт, что в реальности сработает адекватно.
Примерно то же самое можно сказать про защиту от дурака (она же defensive programming). Тем не менее, польза ни у кого не вызывает сомнений.
Что такое errors? Это This repository was archived?
Да. Не знаю что лучше выбрать в 2026. Но вообще никто не запрещает хоть самому велосипед написать. То, что в стандартной библиотеке есть fmt.Errorf и errors — это аргумент, но не причина отказываться от сторонних решений, как никто не отказывается от сторонних HTTP-роутеров.
Исходная версия kaldeon, :
ошибка аккуратно уронила нужный контекст (например текущий запрос)
Для меня «аккуратно уронить» обозначает сделать так, чтобы вызывающему было хорошо. Вызываемая функция может сообщить что пошло не так (“parsing $url as HTML: $err”), сделать удобное определение ошибки (по значению, типу, поведению). Ничто не мешает это повторить в исключениях, но в исключениях мы не ожидаем мгновенной реакции на ошибку, это чья-то другая проблема, поэтому нет стимула напрягаться.
То, что ошибка должна обработаться где-то выше — это естественно. Ненормально заранее не думать об этом.
оставив систему в консистентном состоянии
ACID? Было бы, наверное, хорошо, если весь мир был ACID, но я лично это редко вижу. И здесь обработка ошибок может оказать огромную услугу: неиспользование хранилище будет освобождено, грязные глобальные данные очищены, начатые незаконченные операции отменены, сложные вычисления, ввод пользователя или неполные данные будут сохранены/обработаны.
И этого практически всегда хватает.
«Хватает» в том смысле, что в штате тысяча программистов, готовых разгребать падающие системы хоть каждый день, лишь бы деньги платили?
Хотелось бы долгосрочных улучшений.
Конечно бывают ситуации, когда действительно важно показать пользователю правильное сообщение об ошибке
В идеале всегда. Стек-трейс – это инструмент даже не для программиста, а для разработчика. А пользователем может быть кто угодно, в том числе разработчик. Обработка ошибок позволяет это обеспечить, следуя общему правилу «если f(x) упала, укажи f и x в ошибке».
когда важно обработать ошибку нетривиальным образом и тд и тп, но такие ситуации редки
Они станут ещё реже, если о них вообще не думать. Когда, в сотый раз дополняя ошибку, будешь писать “server failed to respond”, в голову может прийти идея сделать повторный запрос. Или продолжить выполнение с изменённым конфигом. Или проигнорировать и быть уверенным в том, что игнорирование точно уместно (скажем, удаление временных ресурсов), а не кто-то до тебя зачем-то оставил пустой catch-блок.
А в коде безумное множество того, что может выдать ошибку в теории, но на практике не выдаст.
Ещё как выдаст, просто этот момент ещё не наступил. Как раз когда падает самая надёжная операция, больше всего хочется узнать причину.
универсальной обработки для этой [редкой] ошибки хватит за глаза
Стек-трейсы содержат иерархию вызовов и точку отказа. Ни то ни другое не указывает однозначно на природу ошибки и не содержит дополнительного контекста. Можно передать сетевой ресурс за интерфейсом в bufio и ошибку придётся дебажить.
И пытаться обрабатывать все ошибки - верный способ написать уйму кода, который никто никогда не протестирует и который как раз совсем не факт, что в реальности сработает адекватно.
Примерно то же самое можно сказать про защиту от дурака (она же defensive programming). Тем не менее, польза ни у кого не вызывает сомнений.
Что такое errors? Это This repository was archived?
Да. Не знаю что лучше выбрать в 2026. Но вообще никто не запрещает хоть самому велосипед написать. То, что в стандартной библиотеке есть fmt.Errorf и errors — это аргумент, но не причина отказываться от сторонних решений, как никто не отказывается от сторонних HTTP-роутеров.