Стоит ли использовать кастомные исключения в Python

[stepacool]

В веб Python стандартная практика иметь своих наследников Exception, которые ловятся на уровне фреймворка специальными error handler'ами, для выдачи стандартизированных 4хх(а может и 5хх) ошибок. Обычно они имеют свои атрибуты - для детализации ошибки.
Странно, что в статье об этом не упомянуто.

[mixsture]

И возникает необходимость очень хорошего документирования функций (что каждая может выбрасывать). Если про типовые исключения можно как-то предполагать, где будет ValueError, где IndexError — то в кастомных — только доки. Я неоднократно прыгал по функциям вглубь, чтобы где-то в коде откопать кастомное исключение, чтобы потом его перехватывать — удовольствие прям не очень.
Тут я выступлю за подход java: в сигнатуре функции должны содержаться все типы исключений, которые она бросает. Тогда и в кастомных проблем нет — их сразу видно.

[Andrey_Solomatin]

Если KeyError может вылететь из 5 разных мест внутри функции и вам всё равно откуда, тогда да.

> Тут я выступлю за подход java: в сигнатуре функции должны содержаться все типы исключений, которые она бросает.

И потом с этим букетом в сигнатуре функции идёшь вверх по стеку добавляя новые цветочки на каждом уровне.
В веб проекте, в котором я работал, все исключения ловились на самом верху, мы предпочитали RuntimeException бросать.

[Andrey_Solomatin]

Количество пользовательских исключений на проекте должно соответствовать количеству уникальных except кейсов. Если вы не ловите исключения или ловите все на верхнем уровне, то пользовательские не нужны.

В библиотеках чуть по другому, там нужно предугадать, что именно пользователь захочет поймать отдельно.

Чуть отступить от этого подхода можно, когда исключения, это контейнеры для дополнительной информации или фабрика сообщения, например NoLoadOnTruckError из статьи.