1. Некорректности во внешних данных (внешних сервисов или вводимых пользователем).
Примеры: пользователь ввел вместо числа -- символ.
2. Ошибки в коде программы (кривой код).
Примеры: вышли за границу массива, обратились к защищенной памяти, вызвали из другого потока к потоконебезопасный метод.
3. Ошибки системы.
Примеры: недостаточно памяти, аварийное завершение процесса, переполнен стек, недостаточно места на диске, обрыв соединения, нет связи с базой данных.
4. Ошибки прав доступа. -- под вопросом, не знаю куда отнести
Это очень важно. Хотя в .Net (и не только) на причину внимания не обращают.
По идее должно быть 3 базовых класса для всех исключений. Программист смог бы генерировать только исключения "некорректности данных". Системные исключения генерируются Операционной Системой. А исключения "кривого кода" средой исполнения.
Тогда бы все было намного яснее. Если возникло исключени #3 (системное) -- то как правило с ним ничего сделать нельзя -- только показать пользователю, отобразить информацию. Если исключение #2 (кривой код) -- то программист должен исправить ошибку в своей программе. Ну и если #1 -- неверные данные -- то либо пользователь должнен вводить данные правильно (для пользователя эти исключения нужно обрамлять в красивые сообщения об ошибках) либо сообщить в тех. поддержку сервиса, что они выдают ошибочные данные (либо перестроить логику обработки этих данных).
Кстати, ошибки #2 могут породить ошибки #3. И, вроде бы все -- остальные никак не связаны.
Что вы думаете о такой структуризации? И куда отнести ошибки прав доступа? Какие еще есть типы ошибок, которые не вписываются в данную парадигму?
Здравствуйте, 0K, Вы писали:
0K>Все исключения возникают по одной из трех причин:
Еще добавлю
0K>3. Ошибки системы.
Ошибки системы обязательно связаны с физическим устройством: процессором, диском, ОЗУ, сетевой картой и пр. Лишь в редких исключениях мы можем что-то с ними сделать (повторить попытку или переконфигурировать устройство).
4. Ошибки прав доступа.
Сначала хотел отнести к системным. И действительно, иногда физическое устройство определяет кто имеет к нему доступ а кто нет. Но с другой стороны ошибки доступа можно рассматривать как ошибки данных (т.е. реакция на наверно введенный пароль, скажем так). В общем -- пока не знаю. Пусть будут особняком.
Здравствуйте, 0K, Вы писали:
0K>Все исключения возникают по одной из трех причин:
И еще добавлю. Можно еще выделить ошибки нарушения сценария работы. Когда данные вводятся правильные, но они не к месту. Хотя они близки к ошибкам некорректности данных, можно их выделить особняком.
Здравствуйте, 0K, Вы писали:
0K>По идее должно быть 3 базовых класса для всех исключений. Программист смог бы генерировать только исключения "некорректности данных". Системные исключения генерируются Операционной Системой. А исключения "кривого кода" средой исполнения.
Я вот много работаю с DirectX (DirectShow), там куча COM объектов, и все методы могут вернуть код ошибки. И ошибки обычно возвращаются, когда нет нужной версии DirectX'a, когда нет нужного кодека, когда наоборот влез чужой кодек и не дает правильно соединиться, когда нарушен порядок совершения некоторых действий и т.д. Т.е. это далеко не всегда ошибки логики моей программы — они зависят от состояния системы и third-party компонентов, но не зависят от конкретных устройств вроде диска и сети. Что с ними прикажешь делать?
Здравствуйте, D. Mon, Вы писали:
DM>Я вот много работаю с DirectX (DirectShow), там куча COM объектов, и все методы могут вернуть код ошибки. И ошибки обычно возвращаются, когда нет нужной версии DirectX'a, когда нет нужного кодека,
Вы вводите данные в проблемную систему (где возникает исключительная ситуация). Среди этих данных, есть номер нужного кодека или нужной версии DirectX. Система честно отвечает, что не в состоянии обработать эти данные. Т.е. проблема в данных. Вам нужно использовать другую систему, которая эти данные сможет обработать (новую версию).
DM>когда наоборот влез чужой кодек и не дает правильно соединиться,
Проблема данных. Кодек не ожидает таких данных и должен об этом сообщить. А где брать систему, которая сможет эти данные обработать -- это не проблема кодека, это проблема пользователя или админа (ну или программист может предусмотреть реакцию -- скачайте новую версию).
DM>когда нарушен порядок совершения некоторых действий и т.д. Т.е. это далеко не всегда ошибки логики моей программы — они зависят от состояния системы и third-party компонентов, но не зависят от конкретных устройств вроде диска и сети. Что с ними прикажешь делать?
А это выше я добавил: нарушения сценария работы.
Сейчас еще немного подумал. Структурировать можно так:
1.1. Ошибка активных данных: а) корректность данных; б) сценарий обработки данных.
1.2. Ошибка контекстных данных (права доступа).
Здравствуйте, 0K, Вы писали:
0K>По идее должно быть 3 базовых класса для всех исключений. Программист смог бы генерировать только исключения "некорректности данных". Системные исключения генерируются Операционной Системой. А исключения "кривого кода" средой исполнения.
Что же делать программисту, если данные корректны, а код не может их обработать? Откуда об этом узнает среда исполнения?
0K>Тогда бы все было намного яснее. Если возникло исключени #3 (системное) -- то как правило с ним ничего сделать нельзя -- только показать пользователю, отобразить информацию. Если исключение #2 (кривой код) -- то программист должен исправить ошибку в своей программе. Ну и если #1 -- неверные данные -- то либо пользователь должнен вводить данные правильно (для пользователя эти исключения нужно обрамлять в красивые сообщения об ошибках) либо сообщить в тех. поддержку сервиса, что они выдают ошибочные данные (либо перестроить логику обработки этих данных).
0K>Кстати, ошибки #2 могут породить ошибки #3. И, вроде бы все -- остальные никак не связаны.
Тут все в клубок завязано. Например, системные ошибки могут привести к ошибкам данных. И наоборот. Ошибки данных могут быть причиной выявления ошибок кода. Кривой код может порождать ошибки данных.
0K>Что вы думаете о такой структуризации? И куда отнести ошибки прав доступа? Какие еще есть типы ошибок, которые не вписываются в данную парадигму?
Здравствуйте, samius, Вы писали:
S>Что же делать программисту, если данные корректны, а код не может их обработать? Откуда об этом узнает среда исполнения?
Что значит "не может обработать"? Выдает исключение о некорректности данных? Значит для программы данные являются некорректными. Возможно другая программа сможет их обработать (или новая версия этой программы).
S>Тут все в клубок завязано. Например, системные ошибки могут привести к ошибкам данных. И наоборот. Ошибки данных могут быть причиной выявления ошибок кода. Кривой код может порождать ошибки данных.
Ошибки в данных не могут привести к ошибкам соглашений. Они могут лишь ВЫЯВИТЬ, что код был кривым. Историю про старика с бородой и одеялом знаете?
Здравствуйте, 0K, Вы писали:
0K>Здравствуйте, samius, Вы писали:
S>>Что же делать программисту, если данные корректны, а код не может их обработать? Откуда об этом узнает среда исполнения?
0K>Что значит "не может обработать"? Выдает исключение о некорректности данных? Значит для программы данные являются некорректными. Возможно другая программа сможет их обработать (или новая версия этой программы).
Допустим я написал программу чтения doc-ов. Открываю файл. Файл корректный с точки зрения MSOffice, а моя программа его прочитать не может, потому как не смогла. Данные корректны, а программа — нет.
S>>Тут все в клубок завязано. Например, системные ошибки могут привести к ошибкам данных. И наоборот. Ошибки данных могут быть причиной выявления ошибок кода. Кривой код может порождать ошибки данных.
0K>Ошибки в данных не могут привести к ошибкам соглашений. Они могут лишь ВЫЯВИТЬ, что код был кривым. Историю про старика с бородой и одеялом знаете?
Так откуда система узнает о том что код кривой?
Нет, не знаю.
Здравствуйте, 0K, Вы писали:
0K>2. Ошибки в коде программы (кривой код). 0K>Примеры: вышли за границу массива, обратились к защищенной памяти, вызвали из другого потока к потоконебезопасный метод.
Наверное эти ошибки можно разделить на нарушение контракта (метод вызывается с неверными параметрами) и нарушение инварианта (на каком-то этапе работы стало понятно, что состояние объекта испорчено).
Последнее — имхо самое неприятное, т.к. ошибка могла возникнуть задолго до момента возникновения исключения. Если остальные типы ошибок как правило можно локализовать и вернуть состояние в норму, то в данном случае придется или действительно падать, или пытаться откатить само существование проблемного объекта и всех зависимостей.
0K>Начал думать над стратегией обработки исключений.
Но мне кажется эта "классификация" не имеет прямого отношения к обработке исключений.
По непосредственно обработке придерживаюсь следующих (очевидных?) правил:
1. Все исключения должны логироваться + как можно больше данных приведших к ним. Т.е. если была ошибка в базе данных то не плохо было бы видеть сам "плохой" запрос, данные по результатам которых он был сформирован и (на сервере) исходный входящий запрос. При тестировании можно, грубо говоря, запускать батник и проверять что до запуска приложения и после остановки лог пустой, очистка лога на совести человека.
2. Для пользователя надо постараться извернуться и показать какие именно его действия привели к ошибке и как её исправить. И здесь на самом деле не так важно системная ли эта ошибка или входных данных. На сервере разумеется нужно вернуть сообщение как можно менее раскрывающее внутреннее устройство и возможные уязвимости (на клиенте на самом деле тоже, но выбирая между удобством и паранойей я склоняюсь в сторону удобства).
3. Учитывать контекст ошибки. Если ошибка произошла при формировании ячейки таблицы, вряд ли имеет смысл показывать мессадж бокс на каждую из тысячи ячеек.
3. Нужно предусмотреть восстановление состояния до приемлемого уровня по крайней мере для критических мест. Т.е. например если не удалось распарсить конфиг имеет смысл показать сообщение, что файл конфигурации поврежден и будет сброшен на настройки по умолчанию (для энтерпрайзов имеет смысл сохранить поврежденный конфиг для анализов).
Вроде ничего не забыл. При таком раскладе, опять же имхо, то как именно организована иерархия исключений, не так принципиально — в любом случае надо смотреть на контекст и попытаться отобразить наиболее важную информацию. Опять же если исключение совсем нигде не было предусмотрено, то в любом случае ничего кроме мессадж бокса с текстом в исключении не покажешь и немного наивно в такой ситуации решать что делать дальше исходя исключительно из базового класса.
Здравствуйте, 0K, Вы писали:
0K>Что вы думаете о такой структуризации? И куда отнести ошибки прав доступа? Какие еще есть типы ошибок, которые не вписываются в данную парадигму?
У меня другая струтуризация.
1) Logic Exceptions. То, что порождается ассертами, проверка инвариантов. Типа, «Мамой клянусь, в этом состоянии эта переменная должна быть чётной по построению!» Этот тип исключений не обрабатывается в catch-блоке; реакция на этот тип исключений заключается в баг-репорте автору библиотеки.
2) Usage Exception. Порождается при невыполнении контрактов того или иного метода со стороны вызывающего кода. Скажем, метод библиотеки умеет работать только с непустыми строками, и поэтому бросает ArgumentException, если параметр String.IsNullOrWhitespace. Это не проверка правильности аргументов, это проверка того, что правильность аргументов была проверена вызывающим кодом. Этот тип исключений не обрабатывается в catch-блоке; реакция на этот тип исключений заключается в предварительной проверке в пользовательском коде перед вызовом метода выполнения предусловий. Желательно, чтобы текст сообщений состоял из двух предложений: «Что произошло. Как исправить вызывающий код, чтобы исключение не выбрасывалось.»
3) Runtime Exception (название, быть может, не самое удачное). Исключения, которых нельзя избежать в дизайн-тайме. Скажем, FileNotFoundException: ты не можешь проверкой существования файла перед вызовом метода гарантировать, что этот файл будет существовать в следующий момент времени. Именно этот тип исключений обрабатывается в catch-блоке: оборачивается, заменяется, пробрасывается, останавливается.
4) System Failures. Часто, единственной реакцией является FastFail. Скажем, при OutOfMemoryException поздно пить боржоми, возможности обработать исключение может и не быть. Этот тип исключений, имхо, должен пробрасываться до самого внешнего кода.
Здравствуйте, andy1618, Вы писали:
A>Ну почему же? В MSDN в рекомендациях по исключениям как раз довольно A>внятно прописано, какие классы исключений бывают, и что с ними делать.
Простите, причем здесь "классы исключений"? Речь о том, что у них нет структуризации. И нет четкой парадигмы: какие проблемы к каким исключениям приводят.
Здравствуйте, samius, Вы писали:
S>Допустим я написал программу чтения doc-ов. Открываю файл. Файл корректный с точки зрения MSOffice, а моя программа его прочитать не может, потому как не смогла. Данные корректны, а программа — нет.
Программа при этом выбросит исключение? Или просто утеряет часть/все данные?
В идеале ваша программа должна выбросить исключение наследуемое от "некорректные данные". Не важно что для MSOffice или для новой версии MSOffice эти данные корректны. Для вашей программы они не корректны и точка. Вот сделаете новую версию -- данные будут корректны и для нее.
Есть еще второй вариант: предупредить, что часть данных не удалось распарсить. Возможно пользователю не все данные нужны. Так частичная работоспособность программы сохраниться.
S>Так откуда система узнает о том что код кривой?
Ниже человек хорошо объяснил: нарушение контракта (метод вызывается с неверными параметрами) и нарушение инварианта (на каком-то этапе работы стало понятно, что состояние объекта испорчено).
Здравствуйте, 0K, Вы писали:
0K>Здравствуйте, samius, Вы писали:
S>>Допустим я написал программу чтения doc-ов. Открываю файл. Файл корректный с точки зрения MSOffice, а моя программа его прочитать не может, потому как не смогла. Данные корректны, а программа — нет.
0K>Программа при этом выбросит исключение? Или просто утеряет часть/все данные?
Хорошо бы чтобы программа сказала что я не могу прочитать эти данные, а не о том что данные не корректны для неё.
0K>В идеале ваша программа должна выбросить исключение наследуемое от "некорректные данные". Не важно что для MSOffice или для новой версии MSOffice эти данные корректны. Для вашей программы они не корректны и точка. Вот сделаете новую версию -- данные будут корректны и для нее.
Т.е. ты предлагаешь сделать так, что бы например grep анализировал регулярность грамматики входной строки и выкидывал исключение "некорректные данные" в случае чего? Или система должна определить что grep содержит ошибку и не может обработать входную строку?
S>>Так откуда система узнает о том что код кривой?
0K>Ниже человек хорошо объяснил: нарушение контракта (метод вызывается с неверными параметрами) и нарушение инварианта (на каком-то этапе работы стало понятно, что состояние объекта испорчено).
Как система узнает что состояние объекта испорчено-то?
Здравствуйте, git, Вы писали:
git>Наверное эти ошибки можно разделить на нарушение контракта (метод вызывается с неверными параметрами) и нарушение инварианта (на каком-то этапе работы стало понятно, что состояние объекта испорчено).
Спасибо за подсказку. Попытку записи в защищенную память отнести к нарушению инварианта? Или попытку привести объект к несовместимому типу?
git>Но мне кажется эта "классификация" не имеет прямого отношения к обработке исключений.
Еще как имеет. Дело в том, что к каждой из групп применяются схожие правила обработки. Как я уже сказал -- аппаратные ошибки (системные) -- на уровне средней программы исправить скорее всего не удастся. Так что аппаратные ошибки в 90% случаев никак не обрабатываются. Ошибки нарушения контракта/инварианта однозначно говорят о кривости кода (без вариантов). Ошибки связанные с корректностью/правильной последовательностью данных уже связаны с внешним источником -- причин может быть множество.
Четкая структуризация -- залог успеха.
git>1. Все исключения должны логироваться + как можно больше данных приведших к ним. Т.е. если была ошибка в базе данных то не плохо было бы видеть сам "плохой" запрос, данные по результатам которых он был сформирован и (на сервере) исходный входящий запрос. При тестировании можно, грубо говоря, запускать батник и проверять что до запуска приложения и после остановки лог пустой, очистка лога на совести человека.
Еще подумайте как сделать так, чтобы в лог не попали приватные данные (если финансовая система).
git>2. Для пользователя надо постараться извернуться и показать какие именно его действия привели к ошибке и как её исправить. И здесь на самом деле не так важно системная ли эта ошибка или входных данных. На сервере разумеется нужно вернуть сообщение как можно менее раскрывающее внутреннее устройство и возможные уязвимости (на клиенте на самом деле тоже, но выбирая между удобством и паранойей я склоняюсь в сторону удобства).
Внимание! Действие пользователя не может привести к системной ошибке. Только к ошибке данных.
git>Опять же если исключение совсем нигде не было предусмотрено, то в любом случае ничего кроме мессадж бокса с текстом в исключении не покажешь и немного наивно в такой ситуации решать что делать дальше исходя исключительно из базового класса.
Дело даже не в разрешении ситуации на лету по базовому классу (хотя и это возможно иногда) а в лучшей СТРУКТУРИЗАЦИИ. Это очень важно.
Ошибки кода, к примеру, можно сразу отправлять разработкчику. Это 100% его вина. А вот ошибки работы с данными -- под вопросом. Можно даже детали вывести пользователю -- не все дураки, многие поймут в чем дело.
Здравствуйте, Qbit86, Вы писали:
Q>У меня другая струтуризация.
Q>1) Logic Exceptions. То, что порождается ассертами, проверка инвариантов. Типа, «Мамой клянусь, в этом состоянии эта переменная должна быть чётной по построению!» Этот тип исключений не обрабатывается в catch-блоке; реакция на этот тип исключений заключается в баг-репорте автору библиотеки.
Т.е. просто запись в лог и никакой реакции? А вдруг что-то важное? Или программу закрываете?
Q>2) Usage Exception. Порождается при невыполнении контрактов того или иного метода со стороны вызывающего кода. Скажем, метод библиотеки умеет работать только с непустыми строками, и поэтому бросает ArgumentException, если параметр String.IsNullOrWhitespace. Это не проверка правильности аргументов, это проверка того, что правильность аргументов была проверена вызывающим кодом. Этот тип исключений не обрабатывается в catch-блоке; реакция на этот тип исключений заключается в предварительной проверке в пользовательском коде перед вызовом метода выполнения предусловий. Желательно, чтобы текст сообщений состоял из двух предложений: «Что произошло. Как исправить вызывающий код, чтобы исключение не выбрасывалось.»
Ок. Эти исключения в начале метода, скажем ArgumentException созданы для пользователя или для разработчика? Поймет ли пользователь по тексту ошибки что произошло? Или просто увидит имя аргумента, которые для него ничего не значит?
Почему не обрабатываете в cathc? Что пользователь увидит? Системное сообщение об ошибке?
Q>3) Runtime Exception (название, быть может, не самое удачное). Исключения, которых нельзя избежать в дизайн-тайме. Скажем, FileNotFoundException: ты не можешь проверкой существования файла перед вызовом метода гарантировать, что этот файл будет существовать в следующий момент времени. Именно этот тип исключений обрабатывается в catch-блоке: оборачивается, заменяется, пробрасывается, останавливается.
Это ошибка обработки данных. #1. Файл может не существовать, может иметь некорректный формат и пр.
Q>4) System Failures. Часто, единственной реакцией является FastFail. Скажем, при OutOfMemoryException поздно пить боржоми, возможности обработать исключение может и не быть. Этот тип исключений, имхо, должен пробрасываться до самого внешнего кода.
Здравствуйте, samius, Вы писали:
S>Хорошо бы чтобы программа сказала что я не могу прочитать эти данные, а не о том что данные не корректны для неё.
Разницы нет. Что вы напишите пользователю -- ваше дело. Суть в том, что для программы данные не корректны.
S>Т.е. ты предлагаешь сделать так, что бы например grep анализировал регулярность грамматики входной строки и выкидывал исключение "некорректные данные" в случае чего? Или система должна определить что grep содержит ошибку и не может обработать входную строку?
Причем здесь это? Мы говорим просто о структуризации типов исключений.
Вопрос в том, какое исключение вам выбросить, когда поймете что данные не корректны для вашй программы.
S>Как система узнает что состояние объекта испорчено-то?
Контракты и инварианты системы и ваши контракты. К примеру вышли за границу массива или вызвали метод пустого объекта.
Здравствуйте, 0K, Вы писали:
Q>>1) Logic Exceptions... Q>>2) Usage Exceptions...
В общем случае, исключения не являются ошибкой программиста, но первые два типа — являются. В первом случае имеем ошибку автора библиотеки (в которой он сам же и сознаётся), во втором случае — ошибку пользователя библиотеки.
Q>>1) Logic Exceptions... Этот тип исключений не обрабатывается в catch-блоке; реакция на этот тип исключений заключается в баг-репорте автору библиотеки.
0K>Т.е. просто запись в лог и никакой реакции? А вдруг что-то важное? Или программу закрываете?
Если ты используешь функцию сложения в сторонней библиотеке, а она по ошибке вычитает — твои действия? В лог? Окно сообщения? Закрыть программу?
Такие ошибки должны выявляться при тестировании, и глючной 3rd-party-метод просто не используется. В лог (в рантайме) нет особого смысла писать то, что известно в дизайн-тайме (метод не работает). А так — да, где-то у дна стека вызовов обычно есть обработчик неперехваченных исключений, который, например, показывает message box и логирует (программа не падает, но и запрошенная операция не выполняется). Но это ненормальная обработка, при выявлении проблем первых двух типов они должны быть устранены правкой кода.
Q>>2) Usage Exceptions... Этот тип исключений не обрабатывается в catch-блоке; реакция на этот тип исключений заключается в предварительной проверке в пользовательском коде перед вызовом метода выполнения предусловий...
0K>Ок. Эти исключения в начале метода, скажем ArgumentException созданы для пользователя или для разработчика? Поймет ли пользователь по тексту ошибки что произошло? Или просто увидит имя аргумента, которые для него ничего не значит?
Под «пользователем» везде выше я подразумевал разработчика, использующего стороннюю библиотеку, которая бросает исключения. Да, сообщение исключения должно быть таким, чтобы 1) пользователь (разработчик-пользователь библиотеки) понял, в чём проблема; 2) пользователь понял, как её избежать (а не обработать).
0K>Почему не обрабатываете в cathc?
Потому что обрабатываю в if. Утрированный пример:
Так нельзя:
try
{
...
CheckIfExists(login);
...
}
catch (ArgumentException ex)
{
MessageBox.Show("Login must not be empty.");
}
Так можно:
if (String.IsNullOrWhitespace(login))
{
MessageBox.Show("Login must not be empty.");
}
else
{
...
CheckIfExists(login);
...
}
Q>>3) Runtime Exceptions (название, быть может, не самое удачное). Исключения, которых нельзя избежать в дизайн-тайме. Скажем, FileNotFoundException: ты не можешь проверкой существования файла перед вызовом метода гарантировать, что этот файл будет существовать в следующий момент времени. Именно этот тип исключений обрабатывается в catch-блоке: оборачивается, заменяется, пробрасывается, останавливается.
0K>Это ошибка обработки данных. #1. Файл может не существовать, может иметь некорректный формат и пр.
Наоборот. «Ошибка обработки данных» — это частный случай runtime exception. Я свою иерархию не с потолка брал, примерно в таком виде она расписана во «Framework Design Guidelines», 2nd ed. (Но в классах FCL эта иерархия не отражена.)
Здравствуйте, 0K, Вы писали:
0K>Попытку записи в защищенную память отнести к нарушению инварианта?
В большинстве случаев наверное — да
0K>Или попытку привести объект к несовместимому типу?
Здесь уже возможно больше разнообразия — если сигнатура интерфейса скажем требует object, а мы пусть и не явно ожидаем что будет передан Button, то передача чего-то другого — нарушение контракта.
0K>Еще подумайте как сделать так, чтобы в лог не попали приватные данные (если финансовая система).
Вы наверное будете возмущены, но я как раз занимаюсь финансовой системой, и как правило если возникает ошибка на нашей стороне, то клиенты чаще всего готовы предоставить любую информацию включая все пароли лишь бы провести ту операцию которую надо, а надо как правило срочно. И из чисто практических соображений я вижу гораздо больше пользы от того что в логе будет сразу видна причина ошибки, чем неприятности из-за того что возможно кто-то случайно узнает на какую сумму происходила операция.
0K>Внимание! Действие пользователя не может привести к системной ошибке. Только к ошибке данных.
Сходу — попытка открыть слишком большой файл и OutOfMemory, извлечение диска во время прожига, отключение сетевой папки во время работы. это все разве не приводит к системным ошибкам?
0K>Дело даже не в разрешении ситуации на лету по базовому классу (хотя и это возможно иногда) а в лучшей СТРУКТУРИЗАЦИИ. Это очень важно.
Согласен — важно. Но важно скорее не для обработки ошибок, а для общих правил разработки, чтобы у всех было представление какое исключение когда кидается.
Разработчик отвечает за работу определенной функции (или класса, или модуля, или тп). Его функция использует сторонние функции. Его функцию используют другие функции. Отсюда 3 вида ошибок:
1. "Логические" — ошибки внутри моей функции, вызванные неправильным использованием сторонних функций (см п.3). Пытаемся скрыть свои ошибки, логируем (предупреждение), возвращаем результат. Если не получается логируем(ошибка), возвращаем "нашу" ошибку.
2. "Системные" — ошибки в сторонних функциях. Пробуем другие варианты выполнения нужного действия, логируем (предупреждение), возвращаем результат. Если не получается — логируем(ошибка), пробрасываем дальше.
3. "Пользовательские" — ошибки неправильного использования нашей функции. Логируем(отладка), возвращаем ошибку неправильного использования.
Здравствуйте, 0K, Вы писали:
0K>Начал думать над стратегией обработки исключений. 0K>Все исключения возникают по одной из трех причин:
Важно не то по какой причине возникают исключения, а то какая реакция на них возможна, т.к. как их следует обрабатывать. Тогда останется только два варианта: реагируем на исключение или не реагируем. При этом неважно, либо это ошибка пользователя, либо сбой в системе или что-то ещё. По твоей классификации получается, что тип ошибок #1 для твоей программы ожидаем и, соответственно, мы такие ошибки обрабатываем. А системные ошибки вроде закончилось место на диске для твоей программы являются фатальными. Вроде всё правильно. Но, если бы ты писал программу, которая занималась бы, например резервным копированием данных, то всё было бы с точностью до наоборот, ошибки файловой системы обрабатывались бы со всей тщательностью, а реакция на user input (вроде входных параметров) в лучшем случае выдавала бы экран подсказку.
Если нам не помогут, то мы тоже никого не пощадим.
0K>1. Некорректности во внешних данных (внешних сервисов или вводимых пользователем).
0K>Примеры: пользователь ввел вместо числа -- символ.
0K>2. Ошибки в коде программы (кривой код).
0K>Примеры: вышли за границу массива, обратились к защищенной памяти, вызвали из другого потока к потоконебезопасный метод.
0K>3. Ошибки системы.
0K>Примеры: недостаточно памяти, аварийное завершение процесса, переполнен стек, недостаточно места на диске, обрыв соединения, нет связи с базой данных.
0K>4. Ошибки прав доступа. -- под вопросом, не знаю куда отнести
0K>Кстати, ошибки #2 могут породить ошибки #3. И, вроде бы все -- остальные никак не связаны.
Любая ошибка может приводить любой другой.
1 может вызвать
и 2 (хреновая валидация данных и получи деление на ноль)
и 3 (в данных кривой урл вот и нет связи с базой)
и 4 (запросили что-то лишнее)
и так далее и тому подобное.
А вообще такая классификация может быть полезна в рамках оределенного приложения. В рамках другого приложения это все будет ну совсем неуместно.
Здравствуйте, IT, Вы писали:
IT>Важно не то по какой причине возникают исключения, а то какая реакция на них возможна, т.к. как их следует обрабатывать.
Это связано. Прямая связь есть.
Мои программы, к примеру, никогда не обрабатывают аппаратные (системные) исключения. И таких программ большинство.
Но нет возможности узнать аппаратное это исключение или нарушение контракта.
IT>Тогда останется только два варианта: реагируем на исключение или не реагируем.
Реагировать можно по разному. Если аппаратное -- просто занесение в лог (попытка).
Если кривой код -- срочное оповещение программиста. Причем он будет на 100% знать, что это кривой код и его проблема, а не проблема, скажем, оборудования клиента или стороннего сервиса.
Но нет возможности отличить кривой код от аппаратных или проблем обработки данных.
IT>При этом неважно, либо это ошибка пользователя, либо сбой в системе или что-то ещё.
Важно. Еще как важно.
IT>По твоей классификации получается, что тип ошибок #1 для твоей программы ожидаем и, соответственно, мы такие ошибки обрабатываем.
Да. Причем если возникла ошибка данных, значит что-то не так с данными или порядком их обработки.
IT>А системные ошибки вроде закончилось место на диске для твоей программы являются фатальными.
Нет. Я такого не говорил, это вы придумали.
Как поступать с системными ошибками -- решает программа. В 90% случаев она ничего сделать не сможет. Просто занесет в лог. И естественно, Если ошибка системная -- ей лучше закрыться.
Но если программа работает на уровне системы -- она может обработать эту ошибку.
Здравствуйте, GarryIV, Вы писали:
GIV>Любая ошибка может приводить любой другой.
GIV>1 может вызвать GIV>и 2 (хреновая валидация данных и получи деление на ноль)
Вы не правильно поняли. Ошибки 2 (кривой код) -- могут либо существовать либо нет. В процессе работы программы вы их можете ВЫЯВИТЬ. Но если их нет -- то никакими данными вы их не вызовите.
GIV>и 3 (в данных кривой урл вот и нет связи с базой)
Мы не можем знать мысли пользователя -- по этому вполне корректно будет выдать аппаратную ошибку. Концепцию это не нарушает.
GIV>А вообще такая классификация может быть полезна в рамках оределенного приложения. В рамках другого приложения это все будет ну совсем неуместно.
Нет, вы не до конца поняли концепцию. Она полезна для абсолютно всех проектов. Ведь отражает реальную суть вещей, высшая структуризация:
1. Soft
1.1. Code
1.2. Data
1.2.1. Active Data
1.2.1.1. Correct
1.2.1.2. Workflow
1.2.2. Context Data
2. Hard.
Это же не я придумал. Это так компьютер и работа с данными устроена. Просто ошибки должны соответствовать ВЫСШЕЙ СТРУКТУРИЗАЦИИ.
Здравствуйте, 0K, Вы писали:
0K>Нет, вы не до конца поняли концепцию. Она полезна для абсолютно всех проектов. Ведь отражает реальную суть вещей, высшая структуризация:
0K>1. Soft 0K> 1.1. Code 0K> 1.2. Data 0K> 1.2.1. Active Data 0K> 1.2.1.1. Correct 0K> 1.2.1.2. Workflow 0K> 1.2.2. Context Data 0K>2. Hard.
0K>Это же не я придумал. Это так компьютер и работа с данными устроена. Просто ошибки должны соответствовать ВЫСШЕЙ СТРУКТУРИЗАЦИИ.
Давай перейдем от теории к практике. Структурируй, плиз, несколько типичных исключений. Например, InvalidOperationException, ArgumentException, наборчик IOException.
Здравствуйте, 0K, Вы писали:
A>>Ну почему же? В MSDN в рекомендациях по исключениям как раз довольно A>>внятно прописано, какие классы исключений бывают, и что с ними делать.
0K>Простите, причем здесь "классы исключений"?
Вопрос, как я понимаю, риторическо-провокационный
Посмотрите внимательно на названия стандартных классов исключений:
1) "ArgumentException",
2) "ApplicationException",
3) "SystemException".
А теперь посмотрите на вашу классификацию в исходном посте.
Подозрительная корреляция, не так ли?
Но, что мне не нравится, текущий набор стандартных исключений в .NET довольно хаотичен и подобрать подходящее для своей ситуации исключение далеко не всегда удаётся.
0K>Речь о том, что у них нет структуризации. И нет четкой парадигмы: какие проблемы к каким исключениям приводят.
Я не против создания чёткой парадигмы. Просто есть подозрение, что это неподъёмная и неблагодарная задача.
Даже сами Майкрософты признали, что их старое мнение о том, что все пользовательские исключения должны наследоваться от "ApplicationException", оказалось ошибочным:
For most applications, derive custom exceptions from the Exception class. It was originally thought that custom exceptions should derive from the ApplicationException class; however in practice this has not been found to add significant value.
Здравствуйте, samius, Вы писали:
S>Давай перейдем от теории к практике.
Давай.
S>Структурируй, плиз, несколько типичных исключений.
В такой постановке вопрос неразрешим. Микрософт при разработке архитектуры .Net не удилела должного внимания структуризации типов исключений. Даже статья в MSDN по обработке исключений написана в стиле "не делайте так, не делайте эдак". Напоминает объясления на столбе: "дополнительный доход от 100 у.е. в день (не гербалайф)".
Т.е. там не написано КАК работать с исключениями. А написано лишь как НЕ работать. Ибо они сами не очень то хорошо продумали все нюансы.
S>Например, InvalidOperationException,
По идее это исключение нарушения сценария обработки данных (#1). Но опять-же, часто его применяют не по назрачению: когда пытаетесь приветси тип несовместимому (а это уже кривой код #2).
S>ArgumentException,
Здесь еще хуже. Оно может обозначать как нарушение контракта (кривой код), так и неверные данные. В .Net нет четкой структуризации. Такие разные вещи смешиваются.
S>наборчик IOException.
IOException -- должен быть системным (аппаратным). Но у MS не было четкой структуризации и здесь намешали чего только сами хотели. Может быть и проблема данных (файл не сеществует) и, наверное, проблема кода (?).
Здравствуйте, 0K, Вы писали:
S>>ArgumentException, 0K>Здесь еще хуже. Оно может обозначать как нарушение контракта (кривой код), так и неверные данные. В .Net нет четкой структуризации. Такие разные вещи смешиваются.
Здравствуйте, 0K, Вы писали:
0K>Здравствуйте, samius, Вы писали:
S>>Структурируй, плиз, несколько типичных исключений.
0K>Т.е. там не написано КАК работать с исключениями. А написано лишь как НЕ работать. Ибо они сами не очень то хорошо продумали все нюансы.
Это я не буду комментировать.
S>>Например, InvalidOperationException,
0K>По идее это исключение нарушения сценария обработки данных (#1).
Исключение, которое выдается при вызове метода, недопустимого для текущего состояния объекта.
Это можно воспринимать как предусловие, контракт.
Неизвестно, что привело к недопустимому действию для текущего состояния объекта, данные, либо код. Вот такая идея.
0K>Но опять-же, часто его применяют не по назрачению: когда пытаетесь приветси тип несовместимому (а это уже кривой код #2).
Не встречал таких умников. Все можно применить не по назначению. Не надо обвинять в этом меня или майкрософт. От приведения типа, кстати, исключение само вылетает, там не надо ничего больше возбуждать.
S>>ArgumentException,
0K>Здесь еще хуже. Оно может обозначать как нарушение контракта (кривой код), так и неверные данные. В .Net нет четкой структуризации. Такие разные вещи смешиваются.
Типичная проверка предусловий на аргументы. Причем тут дотнет? Так и скажи, что не можешь классифицировать нарушение предусловий в соответствии со своей структуризацией.
S>>наборчик IOException.
0K>IOException -- должен быть системным (аппаратным). Но у MS не было четкой структуризации и здесь намешали чего только сами хотели. Может быть и проблема данных (файл не сеществует) и, наверное, проблема кода (?).
Возьмем конкретный FileNotFoundException. Это проблема кода, данных, или аппаратная?
Возьмем EndOfStreamException. Код, данные, аппаратно?
Забудь про .net и MS. Представь просто ситуацию и классифицируй ее согласно своей структуризации.
Здравствуйте, samius, Вы писали:
S>>>Например, InvalidOperationException,
0K>>По идее это исключение нарушения сценария обработки данных (#1). S>
S>Исключение, которое выдается при вызове метода, недопустимого для текущего состояния объекта.
S>Это можно воспринимать как предусловие, контракт. S>Неизвестно, что привело к недопустимому действию для текущего состояния объекта, данные, либо код. Вот такая идея.
Вы смотрите с точки зрения мальчика, который пытается только понять что там придумали дяди. Я смотрю с точки зрения реальности и понимаю, то что они придумали -- имеет слишком много изъянов.
В том то и дело: InvalidOperationException применяют где ни попади: и при нарушении контракта, и при нарушении сценария работы.
0K>>Но опять-же, часто его применяют не по назрачению: когда пытаетесь приветси тип несовместимому (а это уже кривой код #2). S>Не встречал таких умников. Все можно применить не по назначению. Не надо обвинять в этом меня или майкрософт. От приведения типа, кстати, исключение само вылетает, там не надо ничего больше возбуждать.
Ну опять же, вы смотрите с т.з. неопытного мальчика. Ничего само не вылетает: его выбрасывает код, написанный MS. И они так решили.
S>>>ArgumentException,
0K>>Здесь еще хуже. Оно может обозначать как нарушение контракта (кривой код), так и неверные данные. В .Net нет четкой структуризации. Такие разные вещи смешиваются.
S>Типичная проверка предусловий на аргументы. Причем тут дотнет?
При том, что в спецификации не продумали правила его применения.
S>Так и скажи, что не можешь классифицировать нарушение предусловий в соответствии со своей структуризацией.
А вы не можете разве по моей спецификации? Это контракты. Если возникло такое исключение -- кривой код (вызывавший). Но в .Net это четко не оговорено, по этому если ArgumentException выброшен не из-за кривого кода, а из-за неподходящих данных -- считается нормой.
S>>>наборчик IOException.
0K>>IOException -- должен быть системным (аппаратным). Но у MS не было четкой структуризации и здесь намешали чего только сами хотели. Может быть и проблема данных (файл не сеществует) и, наверное, проблема кода (?).
S>Возьмем конкретный FileNotFoundException. Это проблема кода, данных, или аппаратная?
Проблема данных.
S>Возьмем EndOfStreamException. Код, данные, аппаратно?
Проблема вызывающего кода.
S>Забудь про .net и MS. Представь просто ситуацию и классифицируй ее согласно своей структуризации.
Объясняю еще раз. Эти исключения сами MS применяют без четкой структуризации. Вы .Net воспринимаете как идеальный продукт богов. Я, имея почти 10 летний опыт программирования, вижу что можно было бы улучшить.
0K>Объясняю еще раз. Эти исключения сами MS применяют без четкой структуризации. Вы .Net воспринимаете как идеальный продукт богов. Я, имея почти 10 летний опыт программирования, вижу что можно было бы улучшить.
А я не вижу чем вообще может помочь структуризация. Ты это даже не можешь объяснить. Попытки сделать это с UserFriendlyException привели к тому что ты придумал коды ошибок и текстовые сообщения, что никак не является улучшением.
Если следовать золотому правилу — "не можешь обработать исключение, не лови его", то структуризация и не особо нужна, потому что в каждый момент времени ты будешь перехватывать только конкретные типы. И даже проблемы с InvalidOperationException не возникает, потому что в документации английским по белому написано в каких случаях кидается такое исключение.
Здравствуйте, 0K, Вы писали:
0K>Здравствуйте, samius, Вы писали:
S>>>>Например, InvalidOperationException,
0K>>>По идее это исключение нарушения сценария обработки данных (#1). S>>
S>>Исключение, которое выдается при вызове метода, недопустимого для текущего состояния объекта.
S>>Это можно воспринимать как предусловие, контракт. S>>Неизвестно, что привело к недопустимому действию для текущего состояния объекта, данные, либо код. Вот такая идея.
0K>Вы смотрите с точки зрения мальчика, который пытается только понять что там придумали дяди. Я смотрю с точки зрения реальности и понимаю, то что они придумали -- имеет слишком много изъянов.
0K>В том то и дело: InvalidOperationException применяют где ни попади: и при нарушении контракта, и при нарушении сценария работы.
Бла-бла-бла. Ситуацию недопустимого состояния объекта ты классифицировать не можешь.
0K>>>Но опять-же, часто его применяют не по назрачению: когда пытаетесь приветси тип несовместимому (а это уже кривой код #2). S>>Не встречал таких умников. Все можно применить не по назначению. Не надо обвинять в этом меня или майкрософт. От приведения типа, кстати, исключение само вылетает, там не надо ничего больше возбуждать.
0K>Ну опять же, вы смотрите с т.з. неопытного мальчика. Ничего само не вылетает: его выбрасывает код, написанный MS. И они так решили.
Код выкидывающий InvalidOperationException при приведении типа, который написан MS, в студию. Иначе ты неопытная девочка.
S>>>>ArgumentException,
0K>>>Здесь еще хуже. Оно может обозначать как нарушение контракта (кривой код), так и неверные данные. В .Net нет четкой структуризации. Такие разные вещи смешиваются.
S>>Типичная проверка предусловий на аргументы. Причем тут дотнет?
0K>При том, что в спецификации не продумали правила его применения.
S>>Так и скажи, что не можешь классифицировать нарушение предусловий в соответствии со своей структуризацией.
0K>А вы не можете разве по моей спецификации? Это контракты. Если возникло такое исключение -- кривой код (вызывавший). Но в .Net это четко не оговорено, по этому если ArgumentException выброшен не из-за кривого кода, а из-за неподходящих данных -- считается нормой.
Типа проверять контракты должен вызывающий код?
S>>>>наборчик IOException.
0K>>>IOException -- должен быть системным (аппаратным). Но у MS не было четкой структуризации и здесь намешали чего только сами хотели. Может быть и проблема данных (файл не сеществует) и, наверное, проблема кода (?).
S>>Возьмем конкретный FileNotFoundException. Это проблема кода, данных, или аппаратная?
0K>Проблема данных.
А не кода, который вместо имени файла подсунул прогноз погоды?
S>>Возьмем EndOfStreamException. Код, данные, аппаратно?
0K>Проблема вызывающего кода.
Ну конечно, контракты на содержимое файла должен проверять вызывающий код S>>Забудь про .net и MS. Представь просто ситуацию и классифицируй ее согласно своей структуризации.
0K>Объясняю еще раз. Эти исключения сами MS применяют без четкой структуризации. Вы .Net воспринимаете как идеальный продукт богов. Я, имея почти 10 летний опыт программирования, вижу что можно было бы улучшить.
Я бы постыдился с 10-летним опытом настолько "далеко" видеть.
Здравствуйте, gandjustas, Вы писали:
G>А я не вижу чем вообще может помочь структуризация. Ты это даже не можешь объяснить. Попытки сделать это с UserFriendlyException привели к тому что ты придумал коды ошибок и текстовые сообщения, что никак не является улучшением.
Коды ошибок Где, простите?
Я предлагаю текстовые сообщения генерировать в одном месте (в коде, работающем с предметной областью). А вы предлагаете дублирование кода: каждый, использующий библиотеку должен по кодам ошибок (или, еще хуже, по 500 разным типам исключений) самостоятельно писать тексты ошибок, выводимые пользователю.
G>Если следовать золотому правилу — "не можешь обработать исключение, не лови его",
Вы не поняли идею. Есть информационные исключения. Природа их ясна. Их обработка очень простая -- остановить выполнение операции и отобразить сообщение пользователю.
G>то структуризация и не особо нужна,
Структуризация очень важна. Вы просто не до конца поняли предложенную парадигму.
Мы можем применять сходные правила ко многим типам исключений. И не рискуем нарваться на проблемы (ака перехват аппаратного исключения).
G>потому что в каждый момент времени ты будешь перехватывать только конкретные типы
Как раз таки нет. Почти всегда многие типы нужно обработать совершенно одинаково. Именно по этому существует соблазн написать catch(Exception) (что грозит перехватом и системных исключений).
G>И даже проблемы с InvalidOperationException не возникает, потому что в документации английским по белому написано в каких случаях кидается такое исключение.
Под неверным состоянием объекта там слишком много понимается. Это слишком общее исключение. Просто сложно было структурировать -- они не стали думать об этом.
Здравствуйте, samius, Вы писали:
S>Бла-бла-бла. Ситуацию недопустимого состояния объекта ты классифицировать не можешь.
Я то могу, да вот вы, похоже, никак не можете понять почему "восьмерки боком пишутся".
0K>>>>Но опять-же, часто его применяют не по назрачению: когда пытаетесь приветси тип несовместимому (а это уже кривой код #2). S>>>Не встречал таких умников. Все можно применить не по назначению. Не надо обвинять в этом меня или майкрософт. От приведения типа, кстати, исключение само вылетает, там не надо ничего больше возбуждать.
0K>>Ну опять же, вы смотрите с т.з. неопытного мальчика. Ничего само не вылетает: его выбрасывает код, написанный MS. И они так решили.
S>Код выкидывающий InvalidOperationException при приведении типа, который написан MS, в студию. Иначе ты неопытная девочка.
int? a = null;
int b = (int)a;
Это упрощенно. Можно более запутывающие примеры с той же идеей.
S>Типа проверять контракты должен вызывающий код?
Да. Именно так. Для того контракты и создаются, дабы вызывающий код ни при каких обстоятельствах (с любыми данными) не мог их нарушить. Если нарушил -- проблема кода.
S>>>Возьмем конкретный FileNotFoundException. Это проблема кода, данных, или аппаратная?
0K>>Проблема данных.
S>А не кода, который вместо имени файла подсунул прогноз погоды?
Проблема кода -- это нарушения контрактов/инвариантов. Если код делает не то, что хотел автор но при этом не нарушает контрактов -- это не проблема кода. Код живет свой жизнью.
S>>>Возьмем EndOfStreamException. Код, данные, аппаратно?
0K>>Проблема вызывающего кода.
S>Ну конечно, контракты на содержимое файла должен проверять вызывающий код
Здравствуйте, 0K, Вы писали:
0K>Здравствуйте, gandjustas, Вы писали:
G>>А я не вижу чем вообще может помочь структуризация. Ты это даже не можешь объяснить. Попытки сделать это с UserFriendlyException привели к тому что ты придумал коды ошибок и текстовые сообщения, что никак не является улучшением.
0K>Коды ошибок Где, простите?
Я бы предложил в теле исключения сделать Enum и расшифровку.
0K>Я предлагаю текстовые сообщения генерировать в одном месте (в коде, работающем с предметной областью). А вы предлагаете дублирование кода: каждый, использующий библиотеку должен по кодам ошибок (или, еще хуже, по 500 разным типам исключений) самостоятельно писать тексты ошибок, выводимые пользователю.
Ты так и не привел ответ на мой вопрос в той же теме:
Есть два поля ввода телефона на форме, каждый из них одинаково обрабатывается логикой приложения. Где-то в глубине может выпасть исключение, типа "невозможно определить оператора". Как ты сделаешь выбрасывание исключения в данном случае и отображения ошибки пользователю.
G>>Если следовать золотому правилу — "не можешь обработать исключение, не лови его",
0K>Вы не поняли идею.
Понял
0K>Есть информационные исключения.
Нету таких. Это ты сам придумал.
0K>Природа их ясна. Их обработка очень простая -- остановить выполнение операции и отобразить сообщение пользователю.
Тогда не используй исключения, у них цель другая.
G>>то структуризация и не особо нужна, 0K>Структуризация очень важна. Вы просто не до конца поняли предложенную парадигму.
Это ты придумываешь парадигму, которая вообще говоря насквозь дырявая, а потом пытаешься натянуть её на все исключения.
А структуризация не важна, если следуешь золотому правилу.
0K>Мы можем применять сходные правила ко многим типам исключений. И не рискуем нарваться на проблемы (ака перехват аппаратного исключения).
Еще раз, используй золотое правило, проблем не будет.
G>>потому что в каждый момент времени ты будешь перехватывать только конкретные типы 0K>Как раз таки нет. Почти всегда многие типы нужно обработать совершенно одинаково. Именно по этому существует соблазн написать catch(Exception) (что грозит перехватом и системных исключений).
Это у тебя в голове, я так не пишу и всем сотрудникам запрещаю. А еще FxCop\Code Analisys не дает коммитить такой код.
G>>И даже проблемы с InvalidOperationException не возникает, потому что в документации английским по белому написано в каких случаях кидается такое исключение. 0K>Под неверным состоянием объекта там слишком много понимается. Это слишком общее исключение. Просто сложно было структурировать -- они не стали думать об этом.
А это не имеет значения, имеет значение только то что ты знаешь в конкретном случае. Я знаю что Enumerable.First выкинет InvalidOperationException в случае пустой последовательности, это описано в документации и я буду именно его перехватывать. Мне в этот момент абсолютно все равно на структуризацию.
А если у меня недостаточно сведений о том кто, что, когда и почему бросает, то я не буду ловить исключение, и снова структуризация по барабану.
В книге Framework Design Guidelines есть хороший коммент к этому вопросу в разделе ExceptionHandling.
Ты кстати эту книгу читал?
G>Я бы предложил в теле исключения сделать Enum и расшифровку.
Enum в теле Exception и коды ошибок вместо Exception -- разные вещи. Если на попытку пополнить телефон вы можете получить 500 однотипных (не немножко разных) ответов, то не имеет смысла создавать 500 разных классов исключений -- достаточно в теле одного сделать Enum с этими вариантами ошибок.
G>Ты так и не привел ответ на мой вопрос в той же теме:
G>
G>Есть два поля ввода телефона на форме, каждый из них одинаково обрабатывается логикой приложения. Где-то в глубине может выпасть исключение, типа "невозможно определить оператора". Как ты сделаешь выбрасывание исключения в данном случае и отображения ошибки пользователю.
Предположим пользователь вводит 2 номера: 1 номер отправителя SMS, второй номер получателя.
При таком раскладе есть 2 варианта. Если библиотека уже заточена под отправление и знает что номера должно быть 2 -- то она же в UserFriendlyException и должна сообщить какой именно номер не удалось распознать. Если библиотека просто проверяет номер -- то нужно вызывать по очереди для каждого номера и если ошибка -- посветить этот поле и выдать ошибку.
G>>>Если следовать золотому правилу — "не можешь обработать исключение, не лови его",
G>Понял
Вы подумали что поняли, а на самом деле не поняли.
Текст некоторых исключений должен увидеть пользователь. А каких? Вы знаете?
0K>>Есть информационные исключения. G>Нету таких. Это ты сам придумал.
Вы правы в том, что на данный момент информационные исключения никак не отличают от контрактных и системных. По этому их как бы и нет. Но это не удобно.
0K>>Природа их ясна. Их обработка очень простая -- остановить выполнение операции и отобразить сообщение пользователю. G>Тогда не используй исключения, у них цель другая.
А что тогда использовать? Коды ошибок? Строки?
G>Это ты придумываешь парадигму, которая вообще говоря насквозь дырявая, а потом пытаешься натянуть её на все исключения.
То что вы ее не можете понять -- не делает ее дырявой.
G>А это не имеет значения, имеет значение только то что ты знаешь в конкретном случае. Я знаю что Enumerable.First выкинет InvalidOperationException в случае пустой последовательности, это описано в документации и я буду именно его перехватывать. Мне в этот момент абсолютно все равно на структуризацию.
Скажите пожалуйста. Может ли, к примеру, метод GetContentAsInt класса XmlTextReader выбросить InvalidOperationException?
Вот если бы следовали моей парадигме -- я бы просто знал что при загрузке данных в ридер и при попытке прочесть могут возникнуть только ошибка корректности данных и ошибка сценария обработки данных. А так хрен знает какие исключения он выбросит.
G>А если у меня недостаточно сведений о том кто, что, когда и почему бросает, то я не буду ловить исключение, и снова структуризация по барабану.
Здравствуйте, 0K, Вы писали:
0K>Здравствуйте, gandjustas, Вы писали:
G>>
G>>Я бы предложил в теле исключения сделать Enum и расшифровку.
0K>Enum в теле Exception и коды ошибок вместо Exception -- разные вещи.
То же самое.
0K>Если на попытку пополнить телефон вы можете получить 500 однотипных (не немножко разных) ответов, то не имеет смысла создавать 500 разных классов исключений -- достаточно в теле одного сделать Enum с этими вариантами ошибок.
А ты только то говорил что InvalidOperationException слишком общий и надо структуризировать
G>>Ты так и не привел ответ на мой вопрос в той же теме:
G>>
G>>Есть два поля ввода телефона на форме, каждый из них одинаково обрабатывается логикой приложения. Где-то в глубине может выпасть исключение, типа "невозможно определить оператора". Как ты сделаешь выбрасывание исключения в данном случае и отображения ошибки пользователю.
0K>Вы просто мыслите в своих старых концепциях.
Ты аргументы приводи.
0K>Предположим пользователь вводит 2 номера: 1 номер отправителя SMS, второй номер получателя.
0K>При таком раскладе есть 2 варианта. Если библиотека уже заточена под отправление и знает что номера должно быть 2 -- то она же в UserFriendlyException и должна сообщить какой именно номер не удалось распознать.
То есть будет или два метода проверки телефона (что маловероятно), или UserFriendlyException будет выкидываться выше проверки телефона, тогда собственно все выкидывание UserFriendlyException можно (и даже нужно) перенести в слой PL и вообще избавиться там от исключений, а просто выдавать сообщение пользователю.
0K>Если библиотека просто проверяет номер -- то нужно вызывать по очереди для каждого номера и если ошибка -- посветить этот поле и выдать ошибку.
А как ты узнаешь "это поле", если ты выдаешь пользователю ex.Message?
0K>Текст некоторых исключений должен увидеть пользователь. А каких? Вы знаете?
В идеале — никаких.
0K>>>Есть информационные исключения. G>>Нету таких. Это ты сам придумал.
0K>Вы правы в том, что на данный момент информационные исключения никак не отличают от контрактных и системных. По этому их как бы и нет. Но это не удобно.
Их и не должно быть, для информационных сообщений не стоит использовать такой мощный и громоздкий механизм как исключения.
0K>>>Природа их ясна. Их обработка очень простая -- остановить выполнение операции и отобразить сообщение пользователю. G>>Тогда не используй исключения, у них цель другая. 0K>А что тогда использовать? Коды ошибок? Строки?
Как уже выяснили выше UserFriendlyException будет выбрасываться не там где действительно появляется исключение, а где-то выше, и единственная цель — передать сообщение. Таким образом совершенно нет необходимости создавать exception, надо ловить что вылетело, и как-то формировать строку по этому делу. Собственно с UserFriendlyException надо делать то же самое.
G>>Это ты придумываешь парадигму, которая вообще говоря насквозь дырявая, а потом пытаешься натянуть её на все исключения. 0K>То что вы ее не можете понять -- не делает ее дырявой.
Да я её прекрасно понимаю, а ты не можешь взглянуть на нее критически.
G>>А это не имеет значения, имеет значение только то что ты знаешь в конкретном случае. Я знаю что Enumerable.First выкинет InvalidOperationException в случае пустой последовательности, это описано в документации и я буду именно его перехватывать. Мне в этот момент абсолютно все равно на структуризацию. 0K>Скажите пожалуйста. Может ли, к примеру, метод GetContentAsInt класса XmlTextReader выбросить InvalidOperationException?
0K>Вот его описание: http://msdn.microsoft.com/ru-ru/library/system.xml.xmlreader.readcontentasint.aspx Согласно документации не может. На самом деле может. Как мне об этом узнать? Является ли это багом?
Читай внимательнее (текст в таблице):
Element
XmlDeclaration
None
Document
DocumentType
Notation
Entity
DocumentFragment
Создается исключение InvalidOperationException.
G>>А если у меня недостаточно сведений о том кто, что, когда и почему бросает, то я не буду ловить исключение, и снова структуризация по барабану. 0K>Часто важен не сам тип исключения, а его причина.
И что? Причину всегда можно определить из исключения + документации по конкретному методу.
Здравствуйте, 0K, Вы писали:
0K>Здравствуйте, samius, Вы писали:
S>>Бла-бла-бла. Ситуацию недопустимого состояния объекта ты классифицировать не можешь.
0K>Я то могу, да вот вы, похоже, никак не можете понять почему "восьмерки боком пишутся".
Я напомню, что ты смог:
0K>По идее это исключение нарушения сценария обработки данных (#1).
0K>>>Ну опять же, вы смотрите с т.з. неопытного мальчика. Ничего само не вылетает: его выбрасывает код, написанный MS. И они так решили.
S>>Код выкидывающий InvalidOperationException при приведении типа, который написан MS, в студию. Иначе ты неопытная девочка.
0K>int? a = null; 0K>int b = (int)a;
Уел.
S>>Типа проверять контракты должен вызывающий код?
0K>Да. Именно так. Для того контракты и создаются, дабы вызывающий код ни при каких обстоятельствах (с любыми данными) не мог их нарушить. Если нарушил -- проблема кода.
Значит вызывающий код должен проверять соответствие индекса границам массива, наличие ключа в словаре... Отсутствие культуры — тоже проблема вызывающего кода? Что имя файла не начинается на "lpt1:" проверяешь при создании файла?
S>>>>Возьмем конкретный FileNotFoundException. Это проблема кода, данных, или аппаратная?
0K>>>Проблема данных.
S>>А не кода, который вместо имени файла подсунул прогноз погоды?
0K>Проблема кода -- это нарушения контрактов/инвариантов. Если код делает не то, что хотел автор но при этом не нарушает контрактов -- это не проблема кода. Код живет свой жизнью.
Значит то что нет файла с именем "Привет, Зайка, как дела?" — это проблема данных, а не кода, который попутал текст сообщения с именем файла?
S>>>>Возьмем EndOfStreamException. Код, данные, аппаратно?
0K>>>Проблема вызывающего кода.
S>>Ну конечно, контракты на содержимое файла должен проверять вызывающий код
0K>Нужно знать размер данных в потоке.
Данные пожаты и зашифрованы. Вызывающий код не знает ни ключ, ни структуру данных, может даже не знать о чем они.
Здравствуйте, gandjustas, Вы писали:
0K>>Enum в теле Exception и коды ошибок вместо Exception -- разные вещи. G>То же самое.
Что то же самое? Вы разницу между исключением и кодом возврата знаете? То что внутри исключения есть номер ошибки -- в этом ничего плохого нет.
От кодов возврата отказались, т.к. их можно забыть проверить.
А вы что 500 типов исключений в этом случае стали бы писать?
G>А ты только то говорил что InvalidOperationException слишком общий и надо структуризировать
Его могут использовать и при нарушении инвариантов и при неверном сценарии обработки данных. Вот в этом то и проблема -- такие вещи смешивать нельзя.
0K>>Предположим пользователь вводит 2 номера: 1 номер отправителя SMS, второй номер получателя.
0K>>При таком раскладе есть 2 варианта. Если библиотека уже заточена под отправление и знает что номера должно быть 2 -- то она же в UserFriendlyException и должна сообщить какой именно номер не удалось распознать.
G>То есть будет или два метода проверки телефона (что маловероятно)
Зачем 2 метода? Один метод, который может выбросить разные типы UserFriendlyException. Эти Exception нужно обработать и обязательно отобразить пользователю сообщение. Остальные типы Exception (не предназначенные для пользователя) -- полезной информации для пользователя не содержат.
G>, или UserFriendlyException будет выкидываться выше проверки телефона, тогда собственно все выкидывание UserFriendlyException можно (и даже нужно) перенести в слой PL и вообще избавиться там от исключений, а просто выдавать сообщение пользователю.
Наверное создам пример, дабы всем было понятно. А то мы говорим о разных вещах
0K>>Если библиотека просто проверяет номер -- то нужно вызывать по очереди для каждого номера и если ошибка -- посветить этот поле и выдать ошибку. G>А как ты узнаешь "это поле", если ты выдаешь пользователю ex.Message?
UserFriendlyException кроме сообщения пользователю может содержать много полезной информации.
0K>>Текст некоторых исключений должен увидеть пользователь. А каких? Вы знаете? G>В идеале — никаких.
Ошибаетесь. Нестандартные ситуации в жизни (т.е. в бизнес-процессе, в жизненном процессе) -- так же нужно обрабатывать/отображать с помощью исключений. Это не ошибки в коде -- это ошибки в жизненном процессе.
0K>>Вы правы в том, что на данный момент информационные исключения никак не отличают от контрактных и системных. По этому их как бы и нет. Но это не удобно. G>Их и не должно быть, для информационных сообщений не стоит использовать такой мощный и громоздкий механизм как исключения.
Еще как стоит, если эта информация влияет на ход выполнения программы. Пытаетесь перевести со счета на карту -- исчерпан лимит. Это проблема кода? Нет -- это проблема пользователя и его отношения с банком. Но можно ли продолжать операцию? Нет.
0K>>>>Природа их ясна. Их обработка очень простая -- остановить выполнение операции и отобразить сообщение пользователю. G>>>Тогда не используй исключения, у них цель другая. 0K>>А что тогда использовать? Коды ошибок? Строки? G>Как уже выяснили выше UserFriendlyException будет выбрасываться не там где действительно появляется исключение, а где-то выше, и единственная цель — передать сообщение. Таким образом совершенно нет необходимости создавать exception, надо ловить что вылетело, и как-то формировать строку по этому делу. Собственно с UserFriendlyException надо делать то же самое.
Почему не там? Что-то вы не так поняли.
G>>>А это не имеет значения, имеет значение только то что ты знаешь в конкретном случае. Я знаю что Enumerable.First выкинет InvalidOperationException в случае пустой последовательности, это описано в документации и я буду именно его перехватывать. Мне в этот момент абсолютно все равно на структуризацию. 0K>>Скажите пожалуйста. Может ли, к примеру, метод GetContentAsInt класса XmlTextReader выбросить InvalidOperationException?
0K>>Вот его описание: http://msdn.microsoft.com/ru-ru/library/system.xml.xmlreader.readcontentasint.aspx Согласно документации не может. На самом деле может. Как мне об этом узнать? Является ли это багом? G>Читай внимательнее (текст в таблице): G>
А как я об этом мог узнать из XML-документации? Почему не внесли это исключение в XML-документацию, если по стандарту должны были. Просто в MSDN уже позже дописали.
G>>>А если у меня недостаточно сведений о том кто, что, когда и почему бросает, то я не буду ловить исключение, и снова структуризация по барабану. 0K>>Часто важен не сам тип исключения, а его причина. G>И что? Причину всегда можно определить из исключения + документации по конкретному методу.
Да. Можно. Но разные типы исключений могут иметь одну причину. И наоборот: часто один и тот же тип используют для разных причин. А это очень сильно осложняет процесс разработки.
Здравствуйте, 0K, Вы писали:
0K>Здравствуйте, gandjustas, Вы писали:
0K>>>Enum в теле Exception и коды ошибок вместо Exception -- разные вещи. G>>То же самое.
0K>Что то же самое? Вы разницу между исключением и кодом возврата знаете? То что внутри исключения есть номер ошибки -- в этом ничего плохого нет.
Забавная логика. Мы обсуждаем коды ошибок вместо exception. Ты говоришь что одного типа Exception+код ошибки достаточно для всего, я же говорю что это ничуть не лучше тех самых кодов возврата, от которых долго и упорно пытались уйти те кто исключения придумал.
0K>А вы что 500 типов исключений в этом случае стали бы писать?
Я бы вообще в таком случае исключения не использовал.
0K>>>Предположим пользователь вводит 2 номера: 1 номер отправителя SMS, второй номер получателя.
0K>>>При таком раскладе есть 2 варианта. Если библиотека уже заточена под отправление и знает что номера должно быть 2 -- то она же в UserFriendlyException и должна сообщить какой именно номер не удалось распознать.
G>>То есть будет или два метода проверки телефона (что маловероятно)
0K>Зачем 2 метода? Один метод, который может выбросить разные типы UserFriendlyException. Эти Exception нужно обработать и обязательно отобразить пользователю сообщение. Вот в этом и проблема. Один метод проверяет два разных номера, как пользователю узнать к какому номеру относится сообщение? А если номеров 500?
0K>UserFriendlyException кроме сообщения пользователю может содержать много полезной информации.
А все равно название поля не узнает, так как нету у него этой информации, как и кучи другой информации нету.
0K>>>Текст некоторых исключений должен увидеть пользователь. А каких? Вы знаете? G>>В идеале — никаких.
0K>Ошибаетесь. Нестандартные ситуации в жизни (т.е. в бизнес-процессе, в жизненном процессе) -- так же нужно обрабатывать/отображать с помощью исключений. Это не ошибки в коде -- это ошибки в жизненном процессе.
Обрабатывать — да, отображать — нет.
Ты сам придумал "информационные исключения" и пытаешься что-то всем рассказать, так и не доказав их полезность и применимость. Давай прмиер, там посмотрим.
0K>>>Вы правы в том, что на данный момент информационные исключения никак не отличают от контрактных и системных. По этому их как бы и нет. Но это не удобно. G>>Их и не должно быть, для информационных сообщений не стоит использовать такой мощный и громоздкий механизм как исключения.
0K>Еще как стоит, если эта информация влияет на ход выполнения программы. Пытаетесь перевести со счета на карту -- исчерпан лимит. Это проблема кода? Нет -- это проблема пользователя и его отношения с банком. Но можно ли продолжать операцию? Нет.
А причем тут исключения?
0K>>>>>Природа их ясна. Их обработка очень простая -- остановить выполнение операции и отобразить сообщение пользователю. G>>>>Тогда не используй исключения, у них цель другая. 0K>>>А что тогда использовать? Коды ошибок? Строки? G>>Как уже выяснили выше UserFriendlyException будет выбрасываться не там где действительно появляется исключение, а где-то выше, и единственная цель — передать сообщение. Таким образом совершенно нет необходимости создавать exception, надо ловить что вылетело, и как-то формировать строку по этому делу. Собственно с UserFriendlyException надо делать то же самое.
0K>Почему не там? Что-то вы не так поняли.
Я как раз все так понял, давай пример в коде, я тебе покажу
G>>>>А это не имеет значения, имеет значение только то что ты знаешь в конкретном случае. Я знаю что Enumerable.First выкинет InvalidOperationException в случае пустой последовательности, это описано в документации и я буду именно его перехватывать. Мне в этот момент абсолютно все равно на структуризацию. 0K>>>Скажите пожалуйста. Может ли, к примеру, метод GetContentAsInt класса XmlTextReader выбросить InvalidOperationException?
0K>>>Вот его описание: http://msdn.microsoft.com/ru-ru/library/system.xml.xmlreader.readcontentasint.aspx Согласно документации не может. На самом деле может. Как мне об этом узнать? Является ли это багом? G>>Читай внимательнее (текст в таблице): G>>
0K>А как я об этом мог узнать из XML-документации? Почему не внесли это исключение в XML-документацию, если по стандарту должны были. Просто в MSDN уже позже дописали.
В том то и дело что нет стандарта на xml-документацию.
Обсуждение: http://stackoverflow.com/questions/461306/how-to-document-thrown-exceptions-in-c-net
G>>>>А если у меня недостаточно сведений о том кто, что, когда и почему бросает, то я не буду ловить исключение, и снова структуризация по барабану. 0K>>>Часто важен не сам тип исключения, а его причина. G>>И что? Причину всегда можно определить из исключения + документации по конкретному методу.
0K>Да. Можно. Но разные типы исключений могут иметь одну причину.
Это как?
0K>И наоборот: часто один и тот же тип используют для разных причин. А это очень сильно осложняет процесс разработки.
Пример? Чтобы один метод кидал одно и то же исключение по разным причинам.
Здравствуйте, 0K, Вы писали:
IT>>Важно не то по какой причине возникают исключения, а то какая реакция на них возможна, т.к. как их следует обрабатывать.
0K>Это связано. Прямая связь есть.
Можно выдумать любую связь, только зачем?
0K>Мои программы, к примеру, никогда не обрабатывают аппаратные (системные) исключения. И таких программ большинство. 0K>Но нет возможности узнать аппаратное это исключение или нарушение контракта.
А какая разница с точки зрения поведения твоей программы?
IT>>Тогда останется только два варианта: реагируем на исключение или не реагируем. 0K>Реагировать можно по разному. Если аппаратное -- просто занесение в лог (попытка). 0K>Если кривой код -- срочное оповещение программиста. Причем он будет на 100% знать, что это кривой код и его проблема, а не проблема, скажем, оборудования клиента или стороннего сервиса.
Не пойму. Ты хочешь сказать, если, например, сервер упал по причине аппаратного сбоя, то и фиг с ним. А если он же упал по причине кривого кода, то нужно срочно оповестить программиста? Я думаю, если сервер упал, то нужно прежде всего оповестить службу поддержки и предоставить ей всю исчерпывающую информацию, а уж она решить что с этим всем делать: поднимать на уши админов или программистов.
0K>Но нет возможности отличить кривой код от аппаратных или проблем обработки данных.
И особо не надо.
IT>>При этом неважно, либо это ошибка пользователя, либо сбой в системе или что-то ещё.
0K>Важно. Еще как важно.
В каких-то сценариях, например, с программами архивирования, возможно это и важно. Для большинства обычных приложений совершенно безразлично.
IT>>По твоей классификации получается, что тип ошибок #1 для твоей программы ожидаем и, соответственно, мы такие ошибки обрабатываем.
0K>Да. Причем если возникла ошибка данных, значит что-то не так с данными или порядком их обработки.
Сами данные и порядок их обработки вообще-то разные вещи. Валидация как раз предназначена для того, что убедиться в правильности входных данных. Возможные глюки в порядке обработке она проверить не может никак.
IT>>А системные ошибки вроде закончилось место на диске для твоей программы являются фатальными. 0K>Нет. Я такого не говорил, это вы придумали. 0K>Как поступать с системными ошибками -- решает программа. В 90% случаев она ничего сделать не сможет. Просто занесет в лог. И естественно, Если ошибка системная -- ей лучше закрыться.
Ну то есть являются фатальными
0K>Но если программа работает на уровне системы -- она может обработать эту ошибку.
Какая разница? Не важно на каком уровне ошибка или программа и как их классифицировать. Важно лишь то, как программа собирается реагировать на то или иное вполне конкретное исключение.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>По мне так Application / System гораздо удобней.
А что удобнее то? От ApplicationException теперь не рекомендуют наследоваться. SystemException -- никак не связаны с низкоуровневыми системными исключениями. Иерархии никакой нет...
Если нам не помогут, то мы тоже никого не пощадим.
Где, простите?
