Прямо в сердечко ❤️

💯

Все проверки пользовательского инпута должны быть раньше

💯

Но если типизации нет в языке, то проверить вход надо и зарейзить если дают не то, что мы ждем

А так ли важна типизация? Как будто бы нормально, если вместо валидного order_id метод примет какую-то дичь, не сможет её обработать и выкинет не кастомную ошибку, а общую

возврат None делать только если ордер не найден

Я бы нулл вообще никогда не возвращал, если на выходе метода ожидается объект/коллекция, т.к. это накладывает на вызывающий код бойлерплейтное бремя проверки на нулл. В случае коллекций возвращал бы пустую коллекцию, а в случае объекта - выкидывал бы ошибку OrderNotFoundError

А что значит не сможет отработать? Ну вот ждешь ты строку в виде uuid, а тебе приходит что-то другое. Ты же хочешь узнать, что это что-то другое до того, как, например, совать это в sql запрос? Даже более правильный пример - ждать число, а получить строку, что валидно зайдет в твой запрос, но не является предсказуемым поведением.

Про нулл - я просто не люблю по таким поводам кидать эксепшены. Возможно, ты хочешь показать мне 404 на заказ, которого нет или что-то такое. Для меня исключение - это необработанные случаи. Что-то, что не является стандартным поведением и что надо чинить потенциально. А если чувак ошибся в номере заказа и такого заказа не найдено - то это штатаный режим работы

Ну вот ждешь ты строку в виде uuid, а тебе приходит что-то другое.

Возможно лучше будет проверить тип order_id в вызывающем коде там же, где ты проверяешь order_id на нулл. Это типа fail fast что ли. Если неправильный тип дошёл до запроса в бд, то что-то тут идёт не так. Ну и плюс меньше бойлерплейта, который проверяет типы по всему стеку вызовов

Для меня исключение - это необработанные случаи

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

А вообще для такого вида результатов в некоторых языках есть монады. Типа Result или Option в Rust или Maybe в Haskell. А в Go это делается через множественные аргументы. Так что правильное решение часто зависит от контекста и инструментария. Самое главное - не делать плохо, а способов сделать хорошо всегда несколько :)