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

panic означает, что случилось что-то плохое

Каково определение «чего-то плохого»?

Когда известно, что программа может работать непредсказуемо. Если взять, в примеру, C, то при получении SIGSEGV продолжать работу дальше - напрашиваться на потенциальные проблемы. Для других ЯП классические примеры это нарушение assert-а, выход за пределы массива, разыменование NULL и тд. Это признаки бага в коде, а код с багом по определению работает не так, как задумывал его создатель, поэтому лучше не пытаться продолжать работу.

В го паники обычно возникают при ошибках этого рода.

Но откуда код, из которого исходит panic может знать, что лучше завершить программу? Я могу себе это представить, но такой код не сможет быть повторноиспольумым. И вообще непонятно зачем так делать.

Если очень хочется - панику обработать можно. У неё вполне детерминированное поведение. Но, повторюсь, чаще всего это ошибочно и её обрабатаывать не нужно.

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

Если уж про это рассуждать, то паники обрабатывать можно в следующих случаях:

1. Если программа представляет собой сервер. Падать из-за одного клиента, выдавая ошибку всем остальным, в настоящий момент обрабатываемым клиентам, может казаться неправильным. Хотя при правильной архитектуре, где запущено несколько инстансов сервера и клиенты выполняют retry, ничего страшного в этом я не вижу.

2. Для более корректного завершения работы. К примеру, фесли имеются несохранённые данные, можно попытаться их куда-то сохранить. Опять же при определённом подходе к архитектуре такой ситуации возникать не должно.

Это всё на самом деле признаки архитектурного подхода «fail fast». Когда компоненты системы разрабатываются так, что падение любого из них не является фатальной ошибкой. И в разработке придерживается подход - не пытаться исправлять ошибку вышестоящих, а просто падать. Конечно на определённом уровне должен быть некий гипервизор, обеспечивающий надёжность. Это может быть операционная система с каким-то диспетчером задач, перезапускающим падающие процессы или kubernetes кластер, перезапускающий контейнеры и поды, вообще вроде эта тема из Ерланга пошла давным давно, но с ним я знаком только понаслышке.

panic означает, что случилось что-то плохое

Каково определение «чего-то плохого»?

Когда известно, что программа может работать непредсказуемо. Если взять, в примеру, C, то при получении SIGSEGV продолжать работу дальше - напрашиваться на потенциальные проблемы. Для других ЯП классические примеры это нарушение assert-а, выход за пределы массива, разыменование NULL и тд. Это признаки бага в коде, а код с багом по определению работает не так, как задумывал его создатель, поэтому лучше не пытаться продолжать работу.

В го паники обычно возникают при ошибках этого рода.

Но откуда код, из которого исходит panic может знать, что лучше завершить программу? Я могу себе это представить, но такой код не сможет быть повторноиспольумым. И вообще непонятно зачем так делать.

Если очень хочется - панику обработать можно. У неё вполне детерминированное поведение. Но, повторюсь, чаще всего это ошибочно и её обрабатаывать не нужно.

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

Если уж про это рассуждать, то паники обрабатывать можно в следующих случаях:

1. Если программа представляет собой сервер. Падать из-за одного клиента, выдавая ошибку всем остальным, в настоящий момент обрабатываемым клиентам, может казаться неправильным. Хотя при правильной архитектуре, где запущено несколько инстансов сервера и клиенты выполняют retry, ничего страшного в этом я не вижу.

2. Для более корректного завершения работы. К примеру, фесли имеются несохранённые данные, можно попытаться их куда-то сохранить. Опять же при определённом подходе к архитектуре такой ситуации возникать не должно.

Это всё на самом деле признаки архитектурного подхода «fail fast». Когда компоненты системы разрабатываются так, что падение любого из них не является фатальной ошибкой. И в разработке придерживается подход - не пытаться исправлять ошибку вышестоящих, а просто падать.

panic означает, что случилось что-то плохое

Каково определение «чего-то плохого»?

Когда известно, что программа может работать непредсказуемо. Если взять, в примеру, C, то при получении SIGSEGV продолжать работу дальше - напрашиваться на потенциальные проблемы. Для других ЯП классические примеры это нарушение assert-а, выход за пределы массива, разыменование NULL и тд. Это признаки бага в коде, а код с багом по определению работает не так, как задумывал его создатель, поэтому лучше не пытаться продолжать работу.

В го паники обычно возникают при ошибках этого рода.

Но откуда код, из которого исходит panic может знать, что лучше завершить программу? Я могу себе это представить, но такой код не сможет быть повторноиспольумым. И вообще непонятно зачем так делать.

Если очень хочется - панику обработать можно. У неё вполне детерминированное поведение. Но, повторюсь, чаще всего это ошибочно и её обрабатаывать не нужно.

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

Если уж про это рассуждать, то паники обрабатывать можно в следующих случаях:

1. Если программа представляет собой сервер. Падать из-за одного клиента, выдавая ошибку всем остальным, в настоящий момент обрабатываемым клиентам, может казаться неправильным. Хотя при правильной архитектуре, где запущено несколько инстансов сервера и клиенты выполняют retry, ничего страшного в этом я не вижу.

2. Для более корректного завершения работы. К примеру, если имеются несохранённые данные, можно попытаться их куда-то сохранить. Опять же при определённом подходе к архитектуре такой ситуации возникать не должно.

panic означает, что случилось что-то плохое

Каково определение «чего-то плохого»?

Когда известно, что программа может работать непредсказуемо. Если взять, в примеру, C, то при получении SIGSEGV продолжать работу дальше - напрашиваться на потенциальные проблемы. Для других ЯП классические примеры это нарушение assert-а, выход за пределы массива, разыменование NULL и тд. Это признаки бага в коде, а код с багом по определению работает не так, как задумывал его создатель, поэтому лучше не пытаться продолжать работу.

В го паники обычно возникают при ошибках этого рода.

Но откуда код, из которого исходит panic может знать, что лучше завершить программу? Я могу себе это представить, но такой код не сможет быть повторноиспольумым. И вообще непонятно зачем так делать.

Если очень хочется - панику обработать можно. У неё вполне детерминированное поведение. Но, повторюсь, чаще всего это ошибочно и её обрабатаывать не нужно.

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

panic означает, что случилось что-то плохое

Каково определение «чего-то плохого»?

Когда известно, что программа может работать непредсказуемо. Если взять, в примеру, C, то при получении SIGSEGV продолжать работу дальше - напрашиваться на потенциальные проблемы. Для традиционных ЯП классический пример это нарушение assert-а, выход за пределы массива, разыменование NULL и тд. Это признаки бага в коде, а код с багом по определению работает не так, как задумывал его создатель, поэтому лучше не пытаться продолжать работу.

В го паники обычно возникают при ошибках этого рода.

Но откуда код, из которого исходит panic может знать, что лучше завершить программу? Я могу себе это представить, но такой код не сможет быть повторноиспольумым. И вообще непонятно зачем так делать.

Если очень хочется - панику обработать можно. У неё вполне детерминированное поведение. Но, повторюсь, чаще всего это ошибочно и её обрабатаывать не нужно.

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