Здравствуйте, samius, Вы писали:
S>Проверку придется делать дважды, непосредственно перед операцией, непорседственно в самой операции. Проверка может занимать довольно значительное время.
Может занимать, а может и нет. Это проблема оптимизации, которая далеко не всегда нас волнует, и даже если волнует, посмотри на методы типа TryParse, TryGetValue и т.д.
S>Проверка перед операцией не гарантирует выполнение операции, потому для вызова операции try/catch все равно необходим.
Неправда. Это зависит от ситуации: иногда гарантирует, иногда нет.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, samius, Вы писали:
S>>Проверку придется делать дважды, непосредственно перед операцией, непорседственно в самой операции. Проверка может занимать довольно значительное время. T>Может занимать, а может и нет. Это проблема оптимизации, которая далеко не всегда нас волнует, и даже если волнует, посмотри на методы типа TryParse, TryGetValue и т.д.
Коды ошибок? Да, можно оправдать в случае критических требований к производительности кода. А методы с единственным значением под код ошибки (bool) хороши когда не важна причина неудачи, либо ее можно установить однозначно, как в случае с TryParse и TryGetValue.
Но здесь вроде бы не обсуждаются случаи, когда отказ от исключения в пользу кода ошибки серьезно увеличит производительность. Так к чему были помянуты эти методы? Вариант без предварительной проверки условий выполнения операции был представлен. Правда методом, выкидывающим исключение, а не возвращающим код ошибки.
S>>Проверка перед операцией не гарантирует выполнение операции, потому для вызова операции try/catch все равно необходим. T>Неправда. Это зависит от ситуации: иногда гарантирует, иногда нет.
Ситуация без специальных оговорок предполагает внешние хранилища информации (БД, удаленный сервер, файловая система ...), наличие множества источников изменений состояния системы (в том числе возможность изменения настроек лимита операций). Даже если можно достоверно предположить что лимит не наступит в течении какого-то времени, то гарантировать выполнение операции все равно нельзя.
Здравствуйте, samius, Вы писали:
S>Коды ошибок?
Именно
S>Да, можно оправдать в случае критических требований к производительности кода.
А что, если нет критических требований к производительности кода, то коды возврата использовать нельзя?
S>А методы с единственным значением под код ошибки (bool) хороши когда не важна причина неудачи, либо ее можно установить однозначно, как в случае с TryParse и TryGetValue.
Во-первых, не код ошибки, а скорее код возврата.
Во-вторых никто не мешает сделать так: http://msdn.microsoft.com/en-us/library/ee762437(v=PandP.50).aspx
S>Ситуация без специальных оговорок предполагает внешние хранилища информации (БД, удаленный сервер, файловая система ...),
С чего это вдруг?
лэт ми спик фром май харт
Re[9]: Исключения для пользователя и для программиста -- раз
Здравствуйте, 0K, Вы писали:
M>>Библиотека может передавать на клиента всю необходимую информацию об ошибке. Какие детали выводить пользователю решает программист.
0K>Как раз таки может и должна. Вы думаете почему существует ТРЕБОВАНИЕ ЛОКАЛИЗОВАТЬ СООБЩЕНИЯ ОБ ОШИБКАХ???
Сообщения об ошибках (те которые в UI видно) и исключения имеют мало общего.
Локализированный текст в исключениях зло в 99% случаев. И локализовано может быть не на тот язык и текст не тот и не погуглить нормально.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, samius, Вы писали:
S>>Коды ошибок? T>Именно
S>>Да, можно оправдать в случае критических требований к производительности кода. T>А что, если нет критических требований к производительности кода, то коды возврата использовать нельзя?
Можно, но их хреново комбинировать с исключениями.
S>>А методы с единственным значением под код ошибки (bool) хороши когда не важна причина неудачи, либо ее можно установить однозначно, как в случае с TryParse и TryGetValue. T>Во-первых, не код ошибки, а скорее код возврата.
+1 T>Во-вторых никто не мешает сделать так: http://msdn.microsoft.com/en-us/library/ee762437(v=PandP.50).aspx
Я не знаком с этой технологией. Не уверен, что в результаты валидации можно впихнуть исключение. Полагаю что эта кухня хороша для проверки правильности заполнения формы. Для того чтобы описать таким образом результат операции, потребуется скрестить ежа с ужом, т.е. исключения с неким OperationResults.
S>>Ситуация без специальных оговорок предполагает внешние хранилища информации (БД, удаленный сервер, файловая система ...), T>С чего это вдруг?
"лимит операций" подразумевает банки, кассы, аукционы и т.п. Все это предполагает хранилища данных, многопользовательский доступ. Если ты говоришь о каких-то других лимитах, то дай знать, может я соглашусь с тобой.
Re: Исключения для пользователя и для программиста -- разниц
.... M>Как правило, все исключения поднимаются для разработчиков. Разработчик должен позаботится о том, чтобы пользователь увидел нормальное исключение, а не непонятную, для его мозга, информацию. M>Вы можете вообще не выдавать пользователю никаких исключений, а писать свой текст на своё усмотрение, либо вообще придумать своё поведение приложения.
Ну я рассматриваю этот вопрос еще более формально.
Приложение A, находится в состоянии S и в окружени K.
Пользователь подает команду X. Приложение либо переходит в состояние S2, либо меняет окружение на K2 (это оба успешные варианты развития событий), либо переходит в состояине S3 (отказ выполнить команду X), либо падение приложения с отчетом о причине падения.
Состояние S3 (отказ выполнить команду X) может давать пользователю выбор "вернуться в S, вернуться в S и снова попытаться выполнить X, или что-то еще".
Как видите ни о каких исключениях здесь речи нет.
Но вот в случае падения приложения нужно отобразить исключение, чтобы иметь возможность получить отчет об аварии. Здесь нет никаких "локализаций" и любой другой мишуры. Никаких замен исключений. Однако бывает что используется "ядро" приложения, которое использует библиотеку, которая использует системыне вызовы, и в таком случае исколючения могут выстроиться в цепочку:
CanNotSaveFileException ("ядро")
caused by: IOException (библиотека)
caused by: AccesViolationException "Не могу создать файл abc.xyz, нет доступа на запись в каталог "ffff".
И разумеется в отчете все эти исключения должны присутствовать.
Здравствуйте, midcyber, Вы писали:
M>Ну тогда мой вариант вообще жить не может, всю логику надо строить на исключениях. Учту на будущее.
Ну слава Богу! Хоть до одного дошло. Если бы я говорил -- то ради упрямства бы не принял.
Вот, собственно, для этого и нужны информационно-логические исключения. Кроме того, исключение обязано содержать локализованную информацию для пользователя -- без этого никак.
Re[6]: Исключения для пользователя и для программиста -- раз
Здравствуйте, Sinclair, Вы писали:
S>Ок. Вот это "не удалось подключиться" — это что на самом деле? Это "incorrect login/password" или "unexpected reply during TDS handshake; packet seq=0x23, offset=0x2f"? Или, может быть, "Could not resolve target host name"? Или, скажем, "could not make a connection because target host actively refused it"? А может, это вовсе был "not enough permissions to access target database"?
А вот любой из этих вариантов и пишите. Пользователи не (все) идиоты -- поймут.
Re[12]: Исключения для пользователя и для программиста -- ра
Здравствуйте, Sinclair, Вы писали:
S>Это какая-то очень странная библиотека. Фактически, она заранее знает, какого вида UI будет ею пользоваться. В частности, она почему-то в курсе, что есть пользователь, который выполняет операцию, и которому могут быть интересны подробности.
Какого вида UI -- не имеет значения. Информация об ошибке с UI никак не связана (кроме локализации, но локализацию по правилам нужно делать для всех используемых языков, и это не мое требование).
S>Большинство программистов заинтересованы в написании библиотек, предназначенных для повторного использования. Это означает, что ими будут пользоваться разные приложения с разными стратегиями. Например, метод "перевода денег" будет использован в контексте метода "раскидать деньги участникам кооператива в соответствии с их долями". Здесь вылет исключения из одного из методов ничем не поможет разработчику приложения.
Вы что? Как это не поможет? Еще как поможет. Текст можно вывести в ListBox с результатом проведения операций.
Но обрывать серию операций вовсе не обязательно -- нужно попробовать эту же операцию провести повторно. А вы как хотели -- вообще не выбрасывать исключения?
S>В ситуации, когда очень-очень хочется что-то сказать пользователю, а нельзя, применяют не исключения, а всё же коды ошибок.
Садись, два (с)
S>То есть выбрасывают что-то типа BusinessRuleException, у которого есть список обнаруженных проблем — с кодами (чтобы пользователь мог погуглить) и текстами.
Ну это не то же самое, что код ошибок (которые через return). Но все-же лучше применить Enum без привязки к цифрам.
S>Важность этого исключения не настолько велика, чтобы вносить его ажно во фреймворк — вполне хватит одного на библиотеку. Ведь клиенту библиотеки не нужно реализовывать разную обработку этих ситуаций — значит и классы никакие не нужны.
Я об этом же писал выше. Только вместо просто непонятных цифр (которые еще нужно упомнить) -- применить Enum.
Re[8]: Исключения для пользователя и для программиста -- раз
Здравствуйте, mrTwister, Вы писали:
T>Если эта ситуации ожидаема, то она будет описана в SRS в виде отдельных use-case'в со своей собственной логикой. Реализовывать эту логику через обработчики исключений — это называется использование исключений не по назначению. Таким образом, мы строим логику на исключениях, делая код более запутанным.
Читайте выше как опозорился midcyber с таким же мнением. Вот что изменило его мнение и привело к полному позору:
Даже если программист не забыл вызвать CanComplete, со времени успешной проверки до времени выполнения операции может многое что измениться в системе. Проверка не блокирует записи в БД на изменение! Проверка тут вообще может говорить лишь о прогнозе выполнения операции, потому как если даже она закончилась неудачно, то через пол секунды наступит завтра и счетчики операций будут обнулены.
(с) samius
0K>>А вы знаете что по стандарту все исключения должны быть сериализуемыми? T>Ссылку можно?
MSDN.microsoft.com Запустите FxCop с несериализуемым, там будет конкретная ссылка.
Re[9]: Исключения для пользователя и для программиста -- раз
Здравствуйте, 0K, Вы писали:
0K>Читайте выше как опозорился midcyber с таким же мнением.
Не было никакого позора со стороны midcyber-а. Увидел аргументы, согласился с ними. Это норма поведения. В свою очередь мой ответ ему не связан с желанием опозорить.
Здравствуйте, 0K, Вы писали:
0K>Здравствуйте, midcyber, Вы писали:
M>>Ну тогда мой вариант вообще жить не может, всю логику надо строить на исключениях. Учту на будущее.
0K>Ну слава Богу! Хоть до одного дошло. Если бы я говорил -- то ради упрямства бы не принял.
Я так и думал, что реально вопрос ты не задавал, просто ждал пока кто-то с тобой согласится =)
Re[9]: Исключения для пользователя и для программиста -- раз
G>>Каким образом в глубине приложения можно сформировать информацию для пользователя? Если ругнуться что AccountBalance отрицательный, то это пользователю ничего не даст, такого поля может и не быть на форме.
0K>А кто еще, как ни библиотека, знает все тонкости процесса? Именно библиотека и должна сформировать корректное исключение.
Откуда библиотека, открывающая файл, знает, что это — не просто файл, а файл с днями рождениями пользователя? Ниоткуда. Это знает прикладной код, который использует библиотеку, и который на FileNotFundException сможет сформировать необходимое сообщение пользователю.
Откуда библиотека, парсящая XML, знает, что это за XML и в каком контексте он используется? Ниоткуда. Это знает прикладной код, который использует библиотеку, и который на InvalidXmlException сможет сформировать необходимое сообщение пользователю.
и т.п.
G>>Отлично, и кто будет формировать UserFriendlyException ?
0K>Библиотека, которая напрямую работает с сервисом/базой данных и пр. Или вы предлагаете номера ошибок передавать, а уже в пользовательском интерфейсе сделать сопоставление: номер ошибки — текст????
Нет, в пользовательском интерфейсе обрабатывать возникающие типы ошибок и согласно типам этих ошибок и контексту, в котором они возникают, выдавать необходимые сообщения пользователю.
0K>Вы хоть представляете какую вы сейчас ерунду спороли? Вы знаете сколько может быть вариантов почему деньги со счета на карту перевести не удалось? Около сотни. И вы будете создавать и обрабатывать все 100 типов исключений Атхнитесь!!!
Ошибка там, вообще-то, одна, а не сотни. И при возникновении ошибки там есть код ошибки, согласно которому мы можем точно узнать, что происходит.
Более того, "user friendly" сообщение для части этих ошибок даром не нужны, так как они могут быть типа «карта украдена, обратитесь в полицию», что не надо показывать пользователю.
И срать я хотел на «локализацию» этих ошибок, которые предоставляет банк. Потому что нам банк присылает целых два "user friendly" сообщения — на турецком и английском. При том, что английский там именно, что турецкий по качеству перевода, а турецкий нам даром не нужен, у нас сайт на английском и русском.
Ах, да, я еще хотел срать на 80 из 100 этих ошибок, так как 99% случаев у нас — это неверно введенный номер карточки или expiry date
0K>Смотрите какая парадигма:
0K>1. Есть ошибки, возникающие из-за некорректных данных, введенных пользователем (здесь стараемся не генерировать исключений, сразу проверяем). 0K>2. Есть ошибки нарушения сценария пользователем. Здесь без генерации Exception's не обойтись, но они не являются чем-то непредсказуемым. Их нет смысла заносить в лог. Они не нужны программисту (зачем программисту знать, что в Васи исчерпан лимит операций по счету?).
0K>Вот эти 2 типа ошибок не нужно логировать. Они известны и предсказуемы. Их не нужно исправлять. Они не для программиста а для пользователя.
Неверно. Что первое, что второе могут быть попытками взломать систему, поэтому их надо заносить в лог и обрабатывать соответственно.
Здравствуйте, 0K, Вы писали:
T>>Если эта ситуации ожидаема, то она будет описана в SRS в виде отдельных use-case'в со своей собственной логикой. Реализовывать эту логику через обработчики исключений — это называется использование исключений не по назначению. Таким образом, мы строим логику на исключениях, делая код более запутанным.
0K>Читайте выше как опозорился midcyber с таким же мнением. Вот что изменило его мнение и привело к полному позору:
0K>
0K>Даже если программист не забыл вызвать CanComplete, со времени успешной проверки до времени выполнения операции может многое что измениться в системе. Проверка не блокирует записи в БД на изменение! Проверка тут вообще может говорить лишь о прогнозе выполнения операции, потому как если даже она закончилась неудачно, то через пол секунды наступит завтра и счетчики операций будут обнулены.
К чему ты это написал? Паттерн tester-doer — это не единственный возможный способ организации условной логики.
0K>MSDN.microsoft.com Запустите FxCop с несериализуемым, там будет конкретная ссылка.
S>>>Да, можно оправдать в случае критических требований к производительности кода. T>>А что, если нет критических требований к производительности кода, то коды возврата использовать нельзя? S>Можно, но их хреново комбинировать с исключениями.
Почему? Каждой задаче — свой инструмент. Где-то лучше исключения, где-то коды возврата.
T>>Во-вторых никто не мешает сделать так: http://msdn.microsoft.com/en-us/library/ee762437(v=PandP.50).aspx S>Я не знаком с этой технологией. Не уверен, что в результаты валидации можно впихнуть исключение.
Да легко, можно было бы сделать так, что если данные на форме валидны, то ничего не делать, а если невалидны, то кидать ValidationException. Клиент поймал бы это исключение, и нарисовал красиво какие именно контролы невалидны. Но разработчики Enterprise Library вполне обоснованно не стали так делать, так как пользователю пришлось бы для валидации писать try/catch. Вообще, исключения надо использовать там, где предполагается, что клиент кода будет не ловить эти исключения, а пробрасывать выше. Если мы предполагаем, что клиент кода должен обработать исключение и в соответствии с этим исключением выполнить ту или иную логику, значит лучше вместо исключений использовать коды возврата.
S>"лимит операций" подразумевает банки, кассы, аукционы и т.п. Все это предполагает хранилища данных, многопользовательский доступ. Если ты говоришь о каких-то других лимитах, то дай знать, может я соглашусь с тобой.
Я то думал, что мы обсуждаем способы работы с исключениями, поскольку тема называется "Парадигма работы с исключениями". "лимит операций" — это лишь один из примеров. Но тем не менее, этот пример подразумевает такую вещь, как транзакции, которые защищают нас от проблем с совместным доступом к общим данным.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, samius, Вы писали:
S>>>>Да, можно оправдать в случае критических требований к производительности кода. T>>>А что, если нет критических требований к производительности кода, то коды возврата использовать нельзя? S>>Можно, но их хреново комбинировать с исключениями.
T>Почему?
Почему хреново? Потому как придется и коды проверять и catch-и делать. Лучше что-нибудь одно.
T>Каждой задаче — свой инструмент. Где-то лучше исключения, где-то коды возврата.
Я ж не спорю.
T>>>Во-вторых никто не мешает сделать так: http://msdn.microsoft.com/en-us/library/ee762437(v=PandP.50).aspx S>>Я не знаком с этой технологией. Не уверен, что в результаты валидации можно впихнуть исключение.
T>Да легко, можно было бы сделать так, что если данные на форме валидны, то ничего не делать, а если невалидны, то кидать ValidationException. Клиент поймал бы это исключение, и нарисовал красиво какие именно контролы невалидны. Но разработчики Enterprise Library вполне обоснованно не стали так делать, так как пользователю пришлось бы для валидации писать try/catch. Вообще, исключения надо использовать там, где предполагается, что клиент кода будет не ловить эти исключения, а пробрасывать выше. Если мы предполагаем, что клиент кода должен обработать исключение и в соответствии с этим исключением выполнить ту или иную логику, значит лучше вместо исключений использовать коды возврата.
Одно дело валидация контролов на форме, другое — прогнозирование результата операции.
T>Я то думал, что мы обсуждаем способы работы с исключениями, поскольку тема называется "Парадигма работы с исключениями". "лимит операций" — это лишь один из примеров. Но тем не менее, этот пример подразумевает такую вещь, как транзакции, которые защищают нас от проблем с совместным доступом к общим данным.
А от проблем с сетью и сервером приложений/БД транзакции защитят? Или транзакции сами не выкидывают исключений?
T>>Почему? S>Почему хреново? Потому как придется и коды проверять и catch-и делать. Лучше что-нибудь одно.
catch будет где-то на высоком уровне.
T>>Да легко, можно было бы сделать так, что если данные на форме валидны, то ничего не делать, а если невалидны, то кидать ValidationException. Клиент поймал бы это исключение, и нарисовал красиво какие именно контролы невалидны. Но разработчики Enterprise Library вполне обоснованно не стали так делать, так как пользователю пришлось бы для валидации писать try/catch. Вообще, исключения надо использовать там, где предполагается, что клиент кода будет не ловить эти исключения, а пробрасывать выше. Если мы предполагаем, что клиент кода должен обработать исключение и в соответствии с этим исключением выполнить ту или иную логику, значит лучше вместо исключений использовать коды возврата.
S>Одно дело валидация контролов на форме, другое — прогнозирование результата операции.
При чем тут прогнозирование?
OperationResult PerformOperation()
S>А от проблем с сетью и сервером приложений/БД транзакции защитят? Или транзакции сами не выкидывают исключений?
Проблемы с сетью и пр. имеют мало общего с бизнес-логикой и вполне логично, что обрабатываться они должны совсем иначе. Мы же обсуждаем сейчас бизнес-логику, не так ли?
Атхнитесь!!!