Здравствуйте, antropolog, Вы писали:
S>>Как предпочитает делать большинство? A>в подавляющем большинстве случаев использование исключений это ошибка дизайна.
А подробнее. Вот, открытие несуществующего файла -- нужно выбросить Exception или же вернуть код возврата?
Почему вы считаете, что перевод средств с пустого счета чем то отличается от открытия несуществующего файла?
Re[2]: Опять про исключения бизнес-процесса (2017 год)
Система распределенная и сильно многопоточная. Вот ты проверил, что денег достаточно, начал транзакцию, а бабла-то уже и нет, да и счет закрыт/заблокирован.
Re[3]: Опять про исключения бизнес-процесса (2017 год)
Y> Ожидаемая/неожидаемая — это не всегда бинарное состояние. Что если ожидаемая, но очень редкая?
Как я понимаю, это зависит от способа, которым ты собираешься реагировать на ошибку. Если сразу после возврата из функции — тогда код возврата, если в неопределенном месте сделать откат — тогда исключение. При этом есть переходная "серая" зона, когда для одного и того же метода возможна в одном проекте обработка кода ошибки, а в другом можно спокойно грохнуть приложение. Для каких-то методов должны быть предусмотрены оба варианта (с кодом ошибки и исключением).
Здравствуйте, Shmj, Вы писали:
S>Как сейчас, уже пришли к единому мнению по этому вопросу или нет? Ранее было 2 лагеря, первый из которых был "за" (особенно много представителей в Java-среде), второй против. Доходило до мордобоя...
S>Функция возвращает номер перевода, если успешно. А если не успешно -- возникает исключение. S>Что если денег на счету не достаточно? Выкинуть исключение NotEnoughMoneyException или же обернуть результат в обертку, где будет код возврата (типа успешно -- значит 0, а -100500 -- значит не хватает денег)?
В общем случае ТОЛЬКО исключение. Без вариантов.
Коды ошибок слишком легко проигнорировать.
Например после перевода денег клиенту отправляется товар. Забыли проверить код ошибки — упс, заказчик потерял деньги.
Есть некоторые частные случаи когда можно отойти от этого правила.
Например если перевод денег — конечный результат нужный пользователю. То есть результат будет прямо отображен на экране и не будет больше никак обрабатываться.
Второй пример — "паттерн" TryOperation. Когда положительный и отрицательный результат функции равновероятны и в случае отрицательного результата программа будет делать что-то еще, а не просто прервет операцию. Но даже Try-функции будут кидать исключения в некоторых случаях.
Re[3]: Опять про исключения бизнес-процесса (2017 год)
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, Stanislaw K, Вы писали:
SK>>Предпочитает проверять условия предварительно. S>Что значит предварительно? Вы проверили, денги были. Пока вызвали -- денег уже нет.
Предварительная проверка нужна независимо от спора коды\исключения.
Re[2]: Опять про исключения бизнес-процесса (2017 год)
Здравствуйте, gandjustas, Вы писали:
G>Предварительная проверка нужна независимо от спора коды\исключения.
Где-то на этом форуме уже обсуждали, что попытаться сразу выполнить операцию без предварительных проверок и проще и дешевле. Тем более, что результат такой проверки может стать неактуальным практически мгновенно.
Re[5]: Опять про исключения бизнес-процесса (2017 год)
Здравствуйте, TG, Вы писали:
TG>Здравствуйте, gandjustas, Вы писали:
G>>Предварительная проверка нужна независимо от спора коды\исключения. TG>Где-то на этом форуме уже обсуждали, что попытаться сразу выполнить операцию без предварительных проверок и проще и дешевле. Тем более, что результат такой проверки может стать неактуальным практически мгновенно.
Вот есть примитивная программа, в ней только номер счета отправителя, номер счета получателя и кнопка "отправить".
И есть два варианта:
1) Проверки делать в момент отправки и в случае чего кидать пользователю ошибку.
2) Проверки делать в момент открытия программы и просто делать кнопку "отправить" неактивной.
В 99% случаев более уместен второй вариант. В этом случае операция не будет выполняться если не выполнены предусловия.
Конечно второй вариант будет для программиста сложнее, но тебе в конце концов платят деньги чтобы ты эти сложности преодолевал.
Конечно во втором варианте результат проверки "практически мгновенно" станет неактуальным. Но ты может также "практически мгновенно" его актуализировать. А учитывая, что перевод денег "практически мгновенно" в реальной жизни не происходит, то вполне можно подобрать достаточный интервал для актуализации.
ЗЫ. Самый дорогой ресурс, который ты можешь сэкономить или потратить — время пользователя. Оно прямо связано с расходами на эксплуатацию и с выручкой, если программа продается.
Re[3]: Опять про исключения бизнес-процесса (2017 год)
Здравствуйте, Shmj, Вы писали:
S>Почему вы считаете, что перевод средств с пустого счета чем то отличается от открытия несуществующего файла?
Для пользователя программы отличается, а уж Exception или вернуть код возврата это дело техники (ЯП) и вкусов разработчика, команды или того, кто в ней принимает решения.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[6]: Опять про исключения бизнес-процесса (2017 год)
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, TG, Вы писали:
TG>>Здравствуйте, gandjustas, Вы писали:
G>>>Предварительная проверка нужна независимо от спора коды\исключения. TG>>Где-то на этом форуме уже обсуждали, что попытаться сразу выполнить операцию без предварительных проверок и проще и дешевле. Тем более, что результат такой проверки может стать неактуальным практически мгновенно. G>
Под "предварительными проверками" я имею в виду: достаточно ли денег на счете, не заблокирован ли счет и тому подобное. Т.е. все то, что находится "по ту сторону" функции Transfer() и характеризует состояние внешнего ресурса.
Re[4]: Опять про исключения бизнес-процесса (2017 год)
Здравствуйте, sereginseregin, Вы писали:
S>Речь о том, что функция вернет только краткую техническую информацию, расшифровывать ее все равно придется, поэтому нет смысла заморачиваться со сложными исключениями
Смысл заморачиваться с исключениями в том, что их не проигноришь.
Есть, конечно, вариант, что кто-нибудь напишет пустой catch, но это на порядок проще обнаружить, чем необработанный код возврата.
Re[3]: Опять про исключения бизнес-процесса (2017 год)
S>Давайте ближе к нашему примеру с переводом средств. Вы бы делали NotEnoughMoneyException или код возврата?
S>В guidelines не вижу нигде совета делать коды возврата для данного сценария, наоборот написано "DO NOT return error codes".
S>Перевод средств с пустого счета целиком аналогичен открытию несуществующего файла. Если при открытии несуществующего файла принято выбрасывать исключение, то почему при переводе с пустого счета нужно поступать иначе?
X DO NOT use exceptions for the normal flow of control, if possible.
Except for system failures and operations with potential race conditions, framework designers should design APIs so users can write code that does not throw exceptions. For example, you can provide a way to check preconditions before calling a member so users can write code that does not throw exceptions.
The member used to check preconditions of another member is often referred to as a tester, and the member that actually does the work is called a doer.
There are cases when the Tester-Doer Pattern can have an unacceptable performance overhead. In such cases, the so-called Try-Parse Pattern should be considered (see Exceptions and Performance for more information).
Видятся варианты.
1)
TransferValidationResult ValidateTransfer(int toAccount, decimal amount);
long Transfer(int toAccount, decimal amount); // бросает исключение при неуспехе
2)
bool TryTransfer(int toAccount, decimal amount, out TransferValidationResult transferValidationResult);
S>Функция возвращает номер перевода, если успешно. А если не успешно -- возникает исключение.
Какие-то полумеры. Она должна ставить в очередь и возвращать номер по которому можно отслеживать
что происходит с обработкой данного перевода.
Re[2]: Опять про исключения бизнес-процесса (2017 год)
Здравствуйте, kov_serg, Вы писали:
S>>Функция возвращает номер перевода, если успешно. А если не успешно -- возникает исключение. _>Какие-то полумеры. Она должна ставить в очередь и возвращать номер по которому можно отслеживать _>что происходит с обработкой данного перевода.
В какую очередь?
Re[4]: Опять про исключения бизнес-процесса (2017 год)
Using out or ref parameters requires experience with pointers, understanding how value types and reference types differ, and handling methods with multiple return values. Also, the difference between out and ref parameters is not widely understood. Framework architects designing for a general audience should not expect users to master working with out or ref parameters.
Re[4]: Опять про исключения бизнес-процесса (2017 год)
Y>X DO NOT use exceptions for the normal flow of control, if possible.
Дык... в том то и дело -- в нормальном случае операция проходит и вы отгружаете товар. А если перевести средства не удалось, то это не стандартная ситуация.
Получается есть таки 2 лагеря?
Y>Видятся варианты.
Y>1) Y>TransferValidationResult ValidateTransfer(int toAccount, decimal amount); Y>long Transfer(int toAccount, decimal amount); // бросает исключение при неуспехе
Пред. проверка обычно проходит иначе. Прежде чем пользователь переводит со счета, он видит остаток. Если там 0, то вы просто не отобразите кнопку "перевести средства" в GUI. Если попытается ввести сумму больше, то вы на уровне проверки вводимых данных не дадите этого сделать.
По этому метод Transfer в обычной ситуации отработает, ведь пред. проверки делаютя в любом случае.
Y>2) Y>bool TryTransfer(int toAccount, decimal amount, out TransferValidationResult transferValidationResult);
Вот, никогда не видел ничего подобного. В обычном случае операция проходит, ведь пред. проверки делаются всегда.
Здравствуйте, kov_serg, Вы писали:
S>>Функция возвращает номер перевода, если успешно. А если не успешно -- возникает исключение. _>Какие-то полумеры. Она должна ставить в очередь и возвращать номер по которому можно отслеживать _>что происходит с обработкой данного перевода.
Нет, не должна. Функция настолько оптимизирована, что вы можете вызвать ее 100 тыс. раз в секунду. Это на 3 порядка больше, чем количество пиковых операций в самые нагруженные дни (максимум было 100 операций в секунду).
Если можно обойтись без очереди -- нужно обходиться без очереди.
Пользователю приятнее сделать запрос и сразу же получить результат. Чем получить сообщение "спасибо, ожидайте очереди".
Re[5]: Опять про исключения бизнес-процесса (2017 год)
Здравствуйте, Shmj, Вы писали:
S>Дык... в том то и дело -- в нормальном случае операция проходит и вы отгружаете товар. А если перевести средства не удалось, то это не стандартная ситуация.
Отгружает товар обычно не тот у кого не удалась попытка перевести. Частности конечно, но характерная.
S>Вот, даже наш местный MVP, спец. по guidelines, рекомендует юзать Exception: http://rsdn.org/forum/philosophy/6951261.1
Что юзать (Exception, коды возврата) в значительной степени перпендикулярно тому как организовать обработку ошибок с точки зрения пользователя.
S>Получается есть таки 2 лагеря?
Больше. Но совсем не диаметрально противоположных.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[6]: Опять про исключения бизнес-процесса (2017 год)
Здравствуйте, pagid, Вы писали:
P>Здравствуйте, Shmj, Вы писали:
S>>Дык... в том то и дело -- в нормальном случае операция проходит и вы отгружаете товар. А если перевести средства не удалось, то это не стандартная ситуация. P>Отгружает товар обычно не тот у кого не удалась попытка перевести. Частности конечно, но характерная.
Почему же не тот? Списали с внутреннего счета, оказали услугу.
S>>Вот, даже наш местный MVP, спец. по guidelines, рекомендует юзать Exception: http://rsdn.org/forum/philosophy/6951261.1
