Как сейчас, уже пришли к единому мнению по этому вопросу или нет? Ранее было 2 лагеря, первый из которых был "за" (особенно много представителей в Java-среде), второй против. Доходило до мордобоя...

Классический пример, фукнция перевода денег на счет:

long Transfer(int toAccount, decimal amount);

Функция возвращает номер перевода, если успешно. А если не успешно -- возникает исключение.

Что если денег на счету не достаточно? Выкинуть исключение NotEnoughMoneyException или же обернуть результат в обертку, где будет код возврата (типа успешно -- значит 0, а -100500 -- значит не хватает денег)?

Как предпочитает делать большинство?

Здравствуйте, Shmj, Вы писали:

S>Функция возвращает номер перевода, если успешно. А если не успешно -- возникает исключение.

S>Что если денег на счету не достаточно? Выкинуть исключение NotEnoughMoneyException или же обернуть результат в обертку, где будет код возврата (типа успешно -- значит 0, а -100500 -- значит не хватает денег)?

Кроме нехватки денег может быть еще два десятка причин для отказа, как то "счет заблокирован", "запрещены транзакции через интернет", "банк получателя недоступен", "счет получателя заблокирован"....

S>Как предпочитает делать большинство?

Предпочитает проверять условия предварительно.

Все проблемы от жадности и глупости

Здравствуйте, Stanislaw K, Вы писали:

S>>Как предпочитает делать большинство?
SK>Предпочитает проверять условия предварительно.

В данном примере это не поможет для всех случаев.

Здравствуйте, Shmj, Вы писали:

S>Как предпочитает делать большинство?

Я предпочитаю делить ошибки на "бизнес" и "системные". В твоём примере — это бизнес ошибки, которые должен обрабатывать пользователь программы.

Функция выдаст только название этапа, на котором она споткнулась, так как ограничения в системах (резерв, блокировка счета, технический отказ системы) и сообщения о них для надежности прописываются максимально простым языком. Название этапа не помогает пользователю принять решение. Блокировка счета может быть отменена через секунду после неудачной операции, поэтому пользователю лучше предварительно указать на возможные ошибки с предоставлением максимально подробной информации.

Здравствуйте, Shmj, Вы писали:

S>Как сейчас, уже пришли к единому мнению по этому вопросу или нет? Ранее было 2 лагеря, первый из которых был "за" (особенно много представителей в Java-среде), второй против. Доходило до мордобоя...
Не было двух лагерей. Были люди, не изучившие гайдлайны.

S>Как предпочитает делать большинство?
Большинство предпочитает соблюдать гайдлайны: если это ожидаемая ошибка (например, пользовательский ввод) — не использовать исключения, а проверять явно и возвращать код возврата (или как-то ещё сообщать о неудаче).
Если не ожидаемая — кидать исключение и ловить его где-то в точке возможного восстановления. Или даже не ловить вообще, зависит от приложения.
http://www.informit.com/articles/article.aspx?p=2133373&seqNum=6
https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/exception-throwing

Здравствуйте, sereginseregin, Вы писали:

S>Функция выдаст только название этапа, на котором она споткнулась, так как ограничения в системах (резерв, блокировка счета, технический отказ системы) и сообщения о них для надежности прописываются максимально простым языком. Название этапа не помогает пользователю принять решение. Блокировка счета может быть отменена через секунду после неудачной операции, поэтому пользователю лучше предварительно указать на возможные ошибки с предоставлением максимально подробной информации.

И вот зачем мне, как пользователю, знать какие там у вас ошибки возможны. С моей стороны все ок? Ну и обрабатывайте тогда. Это саппорту надо как можно больше информации.

Здравствуйте, Shmj, Вы писали:

S>Как сейчас, уже пришли к единому мнению по этому вопросу или нет? Ранее было 2 лагеря, первый из которых был "за" (особенно много представителей в Java-среде), второй против. Доходило до мордобоя...

S>Классический пример, фукнция перевода денег на счет:

S>

S>long Transfer(int toAccount, decimal amount);
S>

S>Функция возвращает номер перевода, если успешно. А если не успешно -- возникает исключение.

S>Что если денег на счету не достаточно? Выкинуть исключение NotEnoughMoneyException или же обернуть результат в обертку, где будет код возврата (типа успешно -- значит 0, а -100500 -- значит не хватает денег)?

S>Как предпочитает делать большинство?

Перевод денег это довольно долгая операция поэтому лучше возвращать результат в виде объекта представляющего перевод. В одних случаях мы бросаем исключение(нет денег на счете, счет заблокирован), в других информацию об ошибке клиент получает проверяя статус объекта представляющего перевод денег.

S>>Как предпочитает делать большинство?
V>Большинство предпочитает соблюдать гайдлайны: если это ожидаемая ошибка (например, пользовательский ввод) — не использовать исключения, а проверять явно и возвращать код возврата (или как-то ещё сообщать о неудаче).
V>Если не ожидаемая — кидать исключение и ловить его где-то в точке возможного восстановления. Или даже не ловить вообще, зависит от приложения.

Ответ слишком сферичен в вакууме. Ожидаемая/неожидаемая — это не всегда бинарное состояние. Что если ожидаемая, но очень редкая?

Здравствуйте, yenik, Вы писали:

S>>>Как предпочитает делать большинство?
V>>Большинство предпочитает соблюдать гайдлайны: если это ожидаемая ошибка (например, пользовательский ввод) — не использовать исключения, а проверять явно и возвращать код возврата (или как-то ещё сообщать о неудаче).
V>>Если не ожидаемая — кидать исключение и ловить его где-то в точке возможного восстановления. Или даже не ловить вообще, зависит от приложения.

Y>Ответ слишком сферичен в вакууме. Ожидаемая/неожидаемая — это не всегда бинарное состояние. Что если ожидаемая, но очень редкая?
А вот для ответов на такие вопросы и есть системный архитектор или главный программист, который и должен решать, что как для данного конкретного проекта.
Потому, что без знания специфики проекта это всегда будет сферический ответ в вакууме.
Где-то и на ошибки пользователя можно кидать исключения (например, если полноценная проверка была в предыдущем слое приложения).
А где-то и отсутствующий файл конфигурации или деление на ноль приравнивается к ожидаемой ошибке (если, например, это высокоустойчивая система, которая должена работать любой ценой, даже с риском неправильной работы).

Y>>Ответ слишком сферичен в вакууме. Ожидаемая/неожидаемая — это не всегда бинарное состояние. Что если ожидаемая, но очень редкая?
V>А вот для ответов на такие вопросы и есть системный архитектор или главный программист, который и должен решать, что как для данного конкретного проекта.

Это верно. В сущности, сферичен сам вопрос в стартовом сообщении. Тут следовало бы начать с выяснения особенностей реализуемой системы.

Здравствуйте, Shmj, Вы писали:

S>Как предпочитает делать большинство?

в подавляющем большинстве случаев использование исключений это ошибка дизайна.

Здравствуйте, GarryIV, Вы писали:

GIV>И вот зачем мне, как пользователю, знать какие там у вас ошибки возможны. С моей стороны все ок? Ну и обрабатывайте тогда. Это саппорту надо как можно больше информации.

Т.е. счет заблокировали приставы, или деньги зарезервировали другим поручением — это проблема службы поддержки?

Речь о том, что функция вернет только краткую техническую информацию, расшифровывать ее все равно придется, поэтому нет смысла заморачиваться со сложными исключениями

Здравствуйте, Shmj, Вы писали:

S>Как сейчас, уже пришли к единому мнению по этому вопросу или нет? Ранее было 2 лагеря, первый из которых был "за" (особенно много представителей в Java-среде), второй против. Доходило до мордобоя...

В настоящее время мнение склоняется к "коды ошибок", но активно использются оба подхода.
Либо иерархия исключений, либо sealed hierarchy объектов ошибок, когда компилятор может проверить, что все случаи обработаны.

Всё зависит от стратегии обработки ошибок в программе.

Зависит ли обработка ошибок от типа ошибки? в веб-приложении часто достаточно сказать "500" и записать стектрейс в лог, а где-то все возможные ошибки нужно тщательно обработать. Часто использутся промежуточный вариант, тогда очень важно правильно классифицировать ошибки. Воспроизводимые/случайные. Пользовательские/системные. Известные/неизвестные.

Где обрабатываются ошибки? В месте возникновения или на самом верху?

Должна ли ошибка содержать структурированную информацию о контексте?

И т.п.

Здравствуйте, Stanislaw K, Вы писали:

SK>Предпочитает проверять условия предварительно.

Что значит предварительно? Вы проверили, денги были. Пока вызвали -- денег уже нет.

Здравствуйте, Shmj, Вы писали:

S>Что если денег на счету не достаточно? Выкинуть исключение NotEnoughMoneyException или же обернуть результат в обертку, где будет код возврата (типа успешно -- значит 0, а -100500 -- значит не хватает денег)?

S>Как предпочитает делать большинство?

Сгенерировать TransferException, внутри которого поле "причина" равна -100500, что означает "не хватает денег"

Здравствуйте, Real 3L0, Вы писали:

S>>Как предпочитает делать большинство?

R3>Я предпочитаю делить ошибки на "бизнес" и "системные". В твоём примере — это бизнес ошибки, которые должен обрабатывать пользователь программы.

А как функция сообщит пользователю что ошибка? Вернет код ошибки или сгенерит исключение?

Здравствуйте, sereginseregin, Вы писали:

S>Функция выдаст только название этапа, на котором она споткнулась, так как ограничения в системах (резерв, блокировка счета, технический отказ системы) и сообщения о них для надежности прописываются максимально простым языком. Название этапа не помогает пользователю принять решение. Блокировка счета может быть отменена через секунду после неудачной операции, поэтому пользователю лучше предварительно указать на возможные ошибки с предоставлением максимально подробной информации.

Вопрос вот в чем: будете ли вы использовать механизм Exception или же вернете код ошибки + доп. инфо?

Здравствуйте, vmpire, Вы писали:

S>>Как предпочитает делать большинство?
V>Большинство предпочитает соблюдать гайдлайны: если это ожидаемая ошибка (например, пользовательский ввод) — не использовать исключения, а проверять явно и возвращать код возврата (или как-то ещё сообщать о неудаче).

Пользовательский ввод и ожидаемое исключение (как в Java) -- это несколько разное. К примеру при открытии файла FileNotFoundException -- будет ожидаемым, но вы же не станете в этом случае использовать код возврата?

V>Если не ожидаемая — кидать исключение и ловить его где-то в точке возможного восстановления. Или даже не ловить вообще, зависит от приложения.
V>http://www.informit.com/articles/article.aspx?p=2133373&seqNum=6
V>https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/exception-throwing

Давайте ближе к нашему примеру с переводом средств. Вы бы делали NotEnoughMoneyException или код возврата?

В guidelines не вижу нигде совета делать коды возврата для данного сценария, наоборот написано "DO NOT return error codes".

Перевод средств с пустого счета целиком аналогичен открытию несуществующего файла. Если при открытии несуществующего файла принято выбрасывать исключение, то почему при переводе с пустого счета нужно поступать иначе?

Здравствуйте, Qulac, Вы писали:

Q>Перевод денег это довольно долгая операция поэтому лучше возвращать результат в виде объекта представляющего перевод. В одних случаях мы бросаем исключение(нет денег на счете, счет заблокирован), в других информацию об ошибке клиент получает проверяя статус объекта представляющего перевод денег.

Т.е. вы за Exception? Ну вот, а выше говорят что никаких двух лагеней нет и все считают одинаково...