Сам попал с такую ситуацию и вот что нарыл: http://www.unlocalize.com
По локализованному тексту ошибки выдает оригинальный английский текст. Полезнейший ресурс имхо.
Здравствуйте, Jack128, Вы писали:
J>По локализованному тексту ошибки выдает оригинальный английский текст. Полезнейший ресурс имхо.
Я давно говорил что парадигма обработки ошибок, которую применяет MS, в корне неверная. Исключения предназначенные для разработчиков не нужно переводить.
Здравствуйте, 0K, Вы писали:
0K>Здравствуйте, Jack128, Вы писали:
J>>По локализованному тексту ошибки выдает оригинальный английский текст. Полезнейший ресурс имхо.
0K>Я давно говорил что парадигма обработки ошибок, которую применяет MS, в корне неверная. Исключения предназначенные для разработчиков не нужно переводить.
Вот что ты говорил по этому поводу не так давно:
Без разницы. Кто говорит по-русском -- тому проще искать на русском.
Здравствуйте, 0K, Вы писали:
0K>Я давно говорил что парадигма обработки ошибок, которую применяет MS, в корне неверная. Исключения предназначенные для разработчиков не нужно переводить.
У них парадигма одна, они не разделяют и не пытаются разделить исключения на конечных пользователей, что само по себе верно.
Да, им вот заняться нечем, они будут сидеть и анализировать, какие исключения для пользователей, какие для разработчиков.
То, что пользователь увидел текст исключения — это причина того, что программист просто напросто не перехватил это исключение и не обработал.
Если бы вы были более внимательным, то обратили бы внимание на одну важную вещь: есть исключения только для программистов (ошибка в коде) а есть более предметные: их сообщение выводится пользователю (не только это сообщение (можно добавить пояснение) и не всегда выводится).
Здравствуйте, mrjeka, Вы писали:
M>У них парадигма одна, они не разделяют и не пытаются разделить исключения на конечных пользователей, что само по себе верно.
Если бы это было верно -- вы бы не ныли сейчас всем хором по поводу сабжа. Если бы все Message нужны были исключительно программисту -- они бы имели называние как ошибки в FxCop -- английские слова без пробелов.
Вы не хотите признать истину, т.к. я не авторитет в ваших глазах. Вот скажет вам об этом MS через год-два -- вспомните мои слова.
Здравствуйте, mrjeka, Вы писали:
M>То, что пользователь увидел текст исключения — это причина того, что программист просто напросто не перехватил это исключение и не обработал.
Двойка!
Нужно ставить глобальный обработчик (как сделать -- читайте у Рихтера, могу скинуть вам книгу) и ни в коем случае эту ерунду (типа NullRef... или IndexOutOfR...) пользователю не выводите. Просто напишите "Произошла непредвиденная ошибка". Накой ему ваш NullReferenceException??? Накой спрашиваю?
0K>Нужно ставить глобальный обработчик (как сделать -- читайте у Рихтера, могу скинуть вам книгу) и ни в коем случае эту ерунду (типа NullRef... или IndexOutOfR...) пользователю не выводите. Просто напишите "Произошла непредвиденная ошибка". Накой ему ваш NullReferenceException??? Накой спрашиваю?
А накой ему "непредвиденная ошибка"? Один хрен, в принципе. Но NullReferenceException содержит больше информации, которую пользователь может передать разработчикам. А некоторым пользователям, кстати, впадлу отправить разработчикам автоматический отчет об аварийном завершении, но не впадлу названивать в техподдержку.
Но вообще, я согласен, что программа должна падать настолько цивилизованно, насколько это возможно. Никаких неожиданных мессаджбоксов с сообщениями "Индекс массива имеет недопустимое значение" быть не должно.
Здравствуйте, 0K, Вы писали:
J>>По локализованному тексту ошибки выдает оригинальный английский текст. Полезнейший ресурс имхо.
0K>Я давно говорил что парадигма обработки ошибок, которую применяет MS, в корне неверная. Исключения предназначенные для разработчиков не нужно переводить.
В какой библиотеке, в каком фреймворке "верная парадигма обработки ошибок"?
Нет такой? Странно, не правда ли?
Здравствуйте, GarryIV, Вы писали:
GIV>В какой библиотеке, в каком фреймворке "верная парадигма обработки ошибок"? GIV>Нет такой? Странно, не правда ли?
Нет. Компьютеры и 100 лет не просуществовали. Лет 500-1000 пройдет -- будут правильные парадигмы.
Здравствуйте, SpaceConscience, Вы писали:
SC>А накой ему "непредвиденная ошибка"? Один хрен, в принципе. Но NullReferenceException содержит больше информации, которую пользователь может передать разработчикам. А некоторым пользователям, кстати, впадлу отправить разработчикам автоматический отчет об аварийном завершении, но не впадлу названивать в техподдержку.
Дык отчет нужно отправлять автоматом и без дампа памяти на 100 Мб.
SC>Но вообще, я согласен, что программа должна падать настолько цивилизованно, насколько это возможно. Никаких неожиданных мессаджбоксов с сообщениями "Индекс массива имеет недопустимое значение" быть не должно.
Вот это другой разговор. А поставил минус на первое ваше сообщение, но здесь вы исправились, по этому ставлю и плюс.
Здравствуйте, 0K, Вы писали:
M>>То, что пользователь увидел текст исключения — это причина того, что программист просто напросто не перехватил это исключение и не обработал.
0K>Двойка!
А с чего это мне двойка??
Я не говорил, что мои пользователи видят тексты сообщений исключений
Это вы пытаетесь всем навязать, что должны быть пользовательские и не пользовательские исключения.
БРЕД!!!
MS не ведет такого разделения. Локализация сообщений исключений делается лишь по тому, что если какой-нибудь программист не поставит обработку исключения (не важна причина), то пользователь увидит сообщение на привычном ему языке.
Здравствуйте, mrjeka, Вы писали:
M>MS не ведет такого разделения. Локализация сообщений исключений делается лишь по тому, что если какой-нибудь программист не поставит обработку исключения (не важна причина), то пользователь увидит сообщение на привычном ему языке.
И накой оно ему? Все равно ведь ничего ней поймет. Ну выдаст ему "не задана ссылка на объект". Что обычный пользователь их этого поймет? Причем здесь ссылка, если он вообще сайты не открывал и по ссылкам не ходил?
Текст исключений нужно включать в сообщения об ошибках. И они именно для пользователя. Для программиста удобнее как в FxCop -- английские слова без пробелов.
А тут некоторые этой очевидной истины понять не могут, и теперь ноете всем хором -- не понятно зачем переводили Message. Да не для вас переводили. Просто вы его не умеете использовать + MS допустила грубейшую ошибку в проектировании.
Здравствуйте, 0K, Вы писали:
0K>Здравствуйте, mrjeka, Вы писали:
M>>MS не ведет такого разделения. Локализация сообщений исключений делается лишь по тому, что если какой-нибудь программист не поставит обработку исключения (не важна причина), то пользователь увидит сообщение на привычном ему языке.
0K>И накой оно ему? Все равно ведь ничего ней поймет. Ну выдаст ему "не задана ссылка на объект". Что обычный пользователь их этого поймет? Причем здесь ссылка, если он вообще сайты не открывал и по ссылкам не ходил?
А "Object reference is not set to an instance of an object" понятнее?
Непонятное сообщение вообще-то будет непонятным на любом языке.
0K>Текст исключений нужно включать в сообщения об ошибках. И они именно для пользователя. Для программиста удобнее как в FxCop -- английские слова без пробелов.
Если исключение не перехвачено его пользователь увидит. Такова природа исключений.
0K>А тут некоторые этой очевидной истины понять не могут, и теперь ноете всем хором -- не понятно зачем переводили Message. Да не для вас переводили. Просто вы его не умеете использовать + MS допустила грубейшую ошибку в проектировании.
Какую ошибку?
Здравствуйте, gandjustas, Вы писали:
0K>>И накой оно ему? Все равно ведь ничего ней поймет. Ну выдаст ему "не задана ссылка на объект". Что обычный пользователь их этого поймет? Причем здесь ссылка, если он вообще сайты не открывал и по ссылкам не ходил? G>А "Object reference is not set to an instance of an object" понятнее? G>Непонятное сообщение вообще-то будет непонятным на любом языке.
Куда вам скинуть ссылку на книгу Рихтера? Там написано как делать глобальный обработчик непредвиденных исключений. Нужно написать на языке понятном для пользователя что произошла непредвиденная ошибка. Все остальное вводит его в ступор -- он думает что причина ошибки в его действиях и долго будет думать причем там ссылка, если он сайты вообще не открывал.
0K>>Текст исключений нужно включать в сообщения об ошибках. И они именно для пользователя. Для программиста удобнее как в FxCop -- английские слова без пробелов. G>Если исключение не перехвачено его пользователь увидит. Такова природа исключений.
Глобальный перехватчик обязан быть в любом приложении.
0K>>А тут некоторые этой очевидной истины понять не могут, и теперь ноете всем хором -- не понятно зачем переводили Message. Да не для вас переводили. Просто вы его не умеете использовать + MS допустила грубейшую ошибку в проектировании. G>Какую ошибку?
Ошибку в иерархии исключений. Сначала сделали SystemException для системных а ApplicationException для пользовательских. Потом поняли что это бред и сами же нарушили свою иерархию. Но взамен ничего не предложили -- делай кто что хочет.
А с вам говорить буду только после того как вы напишите свой вариант счетчика.
Здравствуйте, 0K, Вы писали:
0K>И накой оно ему? Все равно ведь ничего ней поймет. Ну выдаст ему "не задана ссылка на объект". Что обычный пользователь их этого поймет? Причем здесь ссылка, если он вообще сайты не открывал и по ссылкам не ходил?
Я уж и не знаю как вам объяснить. Основное будет выделено жирным шрифтом (пардон-с)
Пользователь увидел сообщение исключения — программист не обработал исключение
Пользователю сообщение об ошибке ни о чем не говорит — косяк программиста, что первый увидел такое сообщение
0K>Текст исключений нужно включать в сообщения об ошибках. И они именно для пользователя.
Нифига они не для пользователя. Что выводить пользователю решает программист
0K>А тут некоторые этой очевидной истины понять не могут, и теперь ноете всем хором -- не понятно зачем переводили Message. Да не для вас переводили. Просто вы его не умеете использовать + MS допустила грубейшую ошибку в проектировании.
Это вам кажется что это ошибка проектирования. Сообщения локализуют по одной причине — их может увидеть пользователь потому-что их не перехватил разработчик. Претензии к разработчику!!!
Если бы MS была уверена, что все исключения будут перехвачены и обработаны, то она бы не стала заморачиваться с локализацией текстов сообщений.
Здравствуйте, 0K, Вы писали:
0K>Здравствуйте, gandjustas, Вы писали:
0K>>>И накой оно ему? Все равно ведь ничего ней поймет. Ну выдаст ему "не задана ссылка на объект". Что обычный пользователь их этого поймет? Причем здесь ссылка, если он вообще сайты не открывал и по ссылкам не ходил? G>>А "Object reference is not set to an instance of an object" понятнее? G>>Непонятное сообщение вообще-то будет непонятным на любом языке.
0K>Куда вам скинуть ссылку на книгу Рихтера?
А ты его сам-то читал?
0K>Там написано как делать глобальный обработчик непредвиденных исключений.
Где? Номер страницы.
Class library developers should not even think about unhandled exceptions. Only application
developers need to concern themselves with unhandled exceptions, and the application
should have a policy in place for dealing with unhandled exceptions. Microsoft actually
recommends that application developers just accept the CLR’s default policy.
CLR via C#, 3rd edition, страница 500.
Эта краткая цитата опровергает тонны твоего флейма на форуме.
0K>Нужно написать на языке понятном для пользователя что произошла непредвиденная ошибка.
Датыче?
То есть надо предусмотреть локализацию на несколько языков чтоли? Это оправдано для простого сайта?
0K>Все остальное вводит его в ступор -- он думает что причина ошибки в его действиях и долго будет думать причем там ссылка, если он сайты вообще не открывал.
Пользователь это сообщение даже не прочитает.
0K>>>Текст исключений нужно включать в сообщения об ошибках. И они именно для пользователя. Для программиста удобнее как в FxCop -- английские слова без пробелов. G>>Если исключение не перехвачено его пользователь увидит. Такова природа исключений. 0K>Глобальный перехватчик обязан быть в любом приложении.
Бред. Ты это не сможешь доказать.
Кроме того:
Don’t Catch Everything
CLR via C#, 3rd edition, страница 494.
0K>>>А тут некоторые этой очевидной истины понять не могут, и теперь ноете всем хором -- не понятно зачем переводили Message. Да не для вас переводили. Просто вы его не умеете использовать + MS допустила грубейшую ошибку в проектировании. G>>Какую ошибку?
0K>Ошибку в иерархии исключений. Сначала сделали SystemException для системных а ApplicationException для пользовательских. Потом поняли что это бред и сами же нарушили свою иерархию. Но взамен ничего не предложили -- делай кто что хочет.
А причем тут иерархия, если любое необработанное исключение, следуя "CLR’s default policy" будет показано пользователю.
Можешь придумывать иерархию хоть до посинения, но если ты неправильно пишешь код, то у тебя вылетит NullReferenceException и его увидит пользователь. А писать глобальный catch для него — неверно. Об этом тебе кто угодно расскажет, в том числе рихтер.
0K>А с вам говорить буду только после того как вы напишите свой вариант счетчика.
Я его вообще-то написал, целых два раза. Ты хоть сам читай тему, которую создал.
Здравствуйте, 0K, Вы писали:
0K>>>… + MS допустила грубейшую ошибку в проектировании. G>>Какую ошибку?
0K>Ошибку в иерархии исключений. Сначала сделали SystemException для системных а ApplicationException для пользовательских. Потом поняли что это бред и сами же нарушили свою иерархию.
С доказательной частью у вас очень слабовато. Сначала "нарушили", а потом уже "поняли". Посмотрите сами на список унаследованных от ApplicationException классов и увидите много таких, которые были ещё в самом первом фреймворке.
И это вовсе ни какая не фатальная ошибка: просто нужно взглянуть на вопрос под друнгим углом и данная кривизна выпрямится и не будет чесаться.
0K>Но взамен ничего не предложили -- делай кто что хочет.
Это (выделено болдом мной) самое лучшее предложение, которое могло бы быть. Самое гибкое и самое универсальное.
0K>А с вам говорить буду только после того как вы напишите свой вариант счетчика.
Ой, не говори кума, у самой муж пьяница.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, mrjeka, Вы писали:
M>Пользователь увидел сообщение исключения — программист не обработал исключение M>Пользователю сообщение об ошибке ни о чем не говорит — косяк программиста, что первый увидел такое сообщение M>Это вам кажется что это ошибка проектирования. Сообщения локализуют по одной причине — их может увидеть пользователь потому-что их не перехватил разработчик. Претензии к разработчику!!!
+1
M>Если бы MS была уверена, что все исключения будут перехвачены и обработаны, то она бы не стала заморачиваться с локализацией текстов сообщений.
Многие среды (например, MSSQL) выбрасывают очень разнообразные ошибки. Перпехватывать их все довольно накладно, плюс необходимо учесть и какие-нибудь пользовательские коды. В общем случае, ИМХО, это задача неоправданная, когда как обычные слова "Ошибка при работе с базой данных" пользователя скорее все не удовлетворит: причин может быть много и не только програмист может быть в них повинен (например, пользователю не хватает прав или он просто забыл запустить сервис).
Поэтому ничего страшного в том, что бы показать пользователю текст прилетевшего исключение нет: если уж програмист не знает что делать, может и пользователь сможет исправить ситуацию лучше.
Поэтому "заморачиваться с локализацией текстов сообщений" очень надо. А ужд програмист сам решит, что ему с этой локализацией делать: повеситься или показывать пользователю
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>Поэтому ничего страшного в том, что бы показать пользователю текст прилетевшего исключение нет: если уж програмист не знает что делать, может и пользователь сможет исправить ситуацию лучше.
Ну хоть один авторитет открыто поддержал то что я давно пытаюсь доказать. Как бы это еще gandjustas'у доказать? Может после ваших слов он поймет?
_FR>Поэтому "заморачиваться с локализацией текстов сообщений" очень надо. А ужд програмист сам решит, что ему с этой локализацией делать: повеситься или показывать пользователю
Здравствуйте, gandjustas, Вы писали:
0K>>Куда вам скинуть ссылку на книгу Рихтера? G>А ты его сам-то читал?
Да. Прочитал все об исключениях 2 раза -- ничего нового не узнал. Но Рихтер меня утешил тем, что увидел те же проблемы что и я увидел.
0K>>Там написано как делать глобальный обработчик непредвиденных исключений. G>Где? Номер страницы.
Под рукой сейчас 2-е издание на русском. Стр. 366-374 (если у вас другое издание -- найдете).
G>CLR via C#, 3rd edition, страница 500.
Дорогой вы мой! Там же о библиотеках сказано.
G>Эта краткая цитата опровергает тонны твоего флейма на форуме.
Если бы вы еще поняли о чем там пишут.
0K>>Нужно написать на языке понятном для пользователя что произошла непредвиденная ошибка. G>Датыче? G>То есть надо предусмотреть локализацию на несколько языков чтоли? Это оправдано для простого сайта?
Только на языках предусмотренных на сайте. Исключения для разработчиков переводить не нужно.
Здравствуйте, _FRED_, Вы писали:
_FR>Поэтому ничего страшного в том, что бы показать пользователю текст прилетевшего исключение нет: если уж програмист не знает что делать, может и пользователь сможет исправить ситуацию лучше.
А еще лучше при этом завершить приложение\текущую операцию.
Здравствуйте, 0K, Вы писали:
0K>Здравствуйте, _FRED_, Вы писали:
_FR>>Поэтому ничего страшного в том, что бы показать пользователю текст прилетевшего исключение нет: если уж програмист не знает что делать, может и пользователь сможет исправить ситуацию лучше.
0K>Ну хоть один авторитет открыто поддержал то что я давно пытаюсь доказать.
Нет дорогой, ты пытаешьсо доказать что нужны типы исключений предназначенные только для показа сообщения пользователю. А это в корне неверно.
У тебя вообще с логикой проблемы. Ты считаешь что утверждения "Если А, то Б" и "Если Б, то А" эквивалентны, а это не так.
Кстати если даже сделать типы исключений, то ими просто неудобно пользоваться будет.
_FR>>Поэтому "заморачиваться с локализацией текстов сообщений" очень надо. А ужд програмист сам решит, что ему с этой локализацией делать: повеситься или показывать пользователю 0K>Правильно.
Ты уже третий раз поменял точку зрения?
Здравствуйте, gandjustas, Вы писали:
_FR>>Поэтому ничего страшного в том, что бы показать пользователю текст прилетевшего исключение нет: если уж програмист не знает что делать, может и пользователь сможет исправить ситуацию лучше.
G>А еще лучше при этом завершить приложение\текущую операцию.
Зачем? Можете на вскидку сзазать, по каким причинам при вызове SqlCommand.Execute<…> может прилететь SqlException? Как нужно обработать отсутствие соединения, отсутствие процедуры, недостаток прав или какую-то проблему в самой процедуре? И почему следует закрывать приложение при этом? Если сеть оборвалась, то и нечего дальше работать?
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, 0K, Вы писали:
0K>Здравствуйте, gandjustas, Вы писали:
0K>>>Куда вам скинуть ссылку на книгу Рихтера? G>>А ты его сам-то читал? 0K>Да. Прочитал все об исключениях 2 раза -- ничего нового не узнал. Но Рихтер меня утешил тем, что увидел те же проблемы что и я увидел.
Если ты читал также как читаешь форум, то считай что не читал.
0K>>>Там написано как делать глобальный обработчик непредвиденных исключений. G>>Где? Номер страницы. 0K>Под рукой сейчас 2-е издание на русском. Стр. 366-374 (если у вас другое издание -- найдете).
Да просто приведи текст и название раздела, в новой редакции найдем.
G>>CLR via C#, 3rd edition, страница 500.
0K>Дорогой вы мой! Там же о библиотеках сказано.
Перевожу
Разработчики библиотек не должны даже думать о неперехваченных исключениях.
Только разработчики приложений должны беспокоиться о неперехваченных исключениях,
и приложение должно иметь политику обработки необработанных исключений.
Microsoft рекомендует принимать политику по-умолчанию для CLR
Последняя фраза таки означает что не надо писать глобальный обработчик исключений.
Дошло?
G>>Эта краткая цитата опровергает тонны твоего флейма на форуме. 0K>Если бы вы еще поняли о чем там пишут.
Если бы ты сам понял что доказать пытаешься
А то кажется что единственная твоя цель — доказать что ты круче всех, в том числе пацанов из конторы на букву М.
0K>>>Нужно написать на языке понятном для пользователя что произошла непредвиденная ошибка. G>>Датыче? G>>То есть надо предусмотреть локализацию на несколько языков чтоли? Это оправдано для простого сайта?
0K>Только на языках предусмотренных на сайте. Исключения для разработчиков переводить не нужно.
А Рихтер другого мнения. И что делать если такое исключение таки увидит пользователь?
Здравствуйте, _FRED_, Вы писали:
_FR>Здравствуйте, gandjustas, Вы писали:
_FR>>>Поэтому ничего страшного в том, что бы показать пользователю текст прилетевшего исключение нет: если уж програмист не знает что делать, может и пользователь сможет исправить ситуацию лучше.
G>>А еще лучше при этом завершить приложение\текущую операцию.
_FR>Зачем? Можете на вскидку сзазать, по каким причинам при вызове SqlCommand.Execute<…> может прилететь SqlException?
Не могу, поэтому просто не буду обрабатывать SqlException, что приведет к завершению операции или приложения.
Могу сказать только ситуацию при которой можно продолжать работу после SqlException: нарушение уникальности.
_FR>Как нужно обработать отсутствие соединения, отсутствие процедуры, недостаток прав или какую-то проблему в самой процедуре? И почему следует закрывать приложение при этом?
Как минимум прервать текущую операцию, а в некоторых случаях и закрыть приложение (например если ошибка при старте).
_FR>Если сеть оборвалась, то и нечего дальше работать?
Да, есть другие варианты? Если ocassionaly conected приложение, то там сначала все складывается в локальную базу и подобно ошибки не будет.
Здравствуйте, gandjustas, Вы писали:
_FR>>>>Поэтому ничего страшного в том, что бы показать пользователю текст прилетевшего исключение нет: если уж програмист не знает что делать, может и пользователь сможет исправить ситуацию лучше.
G>>>А еще лучше при этом завершить приложение\текущую операцию.
_FR>>Зачем? Можете на вскидку сзазать, по каким причинам при вызове SqlCommand.Execute<…> может прилететь SqlException? G>Не могу, поэтому просто не буду обрабатывать SqlException, что приведет к завершению операции или приложения. G>Могу сказать только ситуацию при которой можно продолжать работу после SqlException: нарушение уникальности.
Покажите пожалуйста алгоритм, который позволит из, например, SqlException определить, что произошло именнол нарушение уникальности. А как же быть с другими ошибками, как то нарушение ссылочной целостности?
_FR>>Как нужно обработать отсутствие соединения, отсутствие процедуры, недостаток прав или какую-то проблему в самой процедуре? И почему следует закрывать приложение при этом? G>Как минимум прервать текущую операцию,
Можно и прервать, но это к делу не относится.
G>а в некоторых случаях и закрыть приложение (например если ошибка при старте).
А если не на старте? Вы согласны, что коментарий
А еще лучше при этом завершить приложение\текущую операцию.
зачастую не уместен?
_FR>>Если сеть оборвалась, то и нечего дальше работать? G>Да, есть другие варианты?
Конечно.
G>Если ocassionaly conected приложение, то там сначала все складывается в локальную базу и подобно ошибки не будет.
А если это Excel, который замапен на некую внешнюю БД? Если он будет закрываться с необработанной ошибкой, это будет совсем не то, чего ждёт пользователь. Как и в большинстве задач.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>Здравствуйте, gandjustas, Вы писали:
_FR>>>>>Поэтому ничего страшного в том, что бы показать пользователю текст прилетевшего исключение нет: если уж програмист не знает что делать, может и пользователь сможет исправить ситуацию лучше.
G>>>>А еще лучше при этом завершить приложение\текущую операцию.
_FR>>>Зачем? Можете на вскидку сзазать, по каким причинам при вызове SqlCommand.Execute<…> может прилететь SqlException? G>>Не могу, поэтому просто не буду обрабатывать SqlException, что приведет к завершению операции или приложения. G>>Могу сказать только ситуацию при которой можно продолжать работу после SqlException: нарушение уникальности.
_FR>Покажите пожалуйста алгоритм, который позволит из, например, SqlException определить, что произошло именнол нарушение уникальности.
Внтури SqlException есть SqlError, у которого есть Number. Этот Number в точности определяет тип ошибки.
А еще лучше написать запрос, который не упадет в случае нарушения, а потом анализировать affected rows.
_FR>А как же быть с другими ошибками, как то нарушение ссылочной целостности?
А как я его могу исправить? Если внешний ключ, который вводится не вручную, а выбирается из списка в интерфейсе, вдруг оказался невалидным, то единственное что я могу сделать — сказать "ололо кто-то поменял данные и надо перезапустить операцию".
_FR>>>Как нужно обработать отсутствие соединения, отсутствие процедуры, недостаток прав или какую-то проблему в самой процедуре? И почему следует закрывать приложение при этом? G>>Как минимум прервать текущую операцию,
_FR>Можно и прервать, но это к делу не относится.
Как раз относится.
G>>а в некоторых случаях и закрыть приложение (например если ошибка при старте).
_FR>А если не на старте?
Тогда прервать операцию.
_FR>Вы согласны, что коментарий
А еще лучше при этом завершить приложение\текущую операцию.
зачастую не уместен?
Нет, это зачастую самое лучшее решение.
не забывай что большинство exception пользователь видит если в программе явно баг. А если пользователь испытывает неудобства из-за этого, то баг будет исправлен быстрее.
_FR>>>Если сеть оборвалась, то и нечего дальше работать? G>>Да, есть другие варианты? _FR>Конечно.
Например?
G>>Если ocassionaly conected приложение, то там сначала все складывается в локальную базу и подобно ошибки не будет.
_FR>А если это Excel, который замапен на некую внешнюю БД? Если он будет закрываться с необработанной ошибкой, это будет совсем не то, чего ждёт пользователь.
Он как раз ocassionaly conected. Данные хранит локально и синхронизирует с БД.
_FR>Как и в большинстве задач.
Нет. Как раз в большинстве задач нарушение связи с БД означает невозможность дальнейшей работы.
Здравствуйте, gandjustas, Вы писали:
0K>>Да. Прочитал все об исключениях 2 раза -- ничего нового не узнал. Но Рихтер меня утешил тем, что увидел те же проблемы что и я увидел. G>Если ты читал также как читаешь форум, то считай что не читал.
То же самое могу сказать про вас. Читаете между строк и только то что вам нравится. Ниже я это докажу.
G>Да просто приведи текст и название раздела, в новой редакции найдем.
Так и называется: работа с unhandled exception (отдельная статья для WinForm, WebForm и пр.).
G>Перевожу
G>
G>Разработчики библиотек не должны даже думать о неперехваченных исключениях.
G>Только разработчики приложений должны беспокоиться о неперехваченных исключениях,
G>и приложение должно иметь политику обработки необработанных исключений.
G>Microsoft рекомендует принимать политику по-умолчанию для CLR
G>Последняя фраза таки означает что не надо писать глобальный обработчик исключений.
Вот это то о чем я говорил. Первые 2 фразы вы не увидели.
разработчики приложений должны беспокоиться о неперехваченных исключениях разработчики приложений должны беспокоиться о неперехваченных исключениях разработчики приложений должны беспокоиться о неперехваченных исключениях
Дошло? Или вы называете заботой -- оставить не вполне ясное окошко с текстом ошибки? Нафига?
0K>>Только на языках предусмотренных на сайте. Исключения для разработчиков переводить не нужно. G>А Рихтер другого мнения. И что делать если такое исключение таки увидит пользователь?
Если исключение предназначено исключительно для разработчика -- пусть лучше увидит его на английском. Глобализация, английский все в школах учат -- поймет что это вы чего-то недоработали.
Здравствуйте, 0K, Вы писали:
0K>Здравствуйте, gandjustas, Вы писали:
0K>>>Да. Прочитал все об исключениях 2 раза -- ничего нового не узнал. Но Рихтер меня утешил тем, что увидел те же проблемы что и я увидел. G>>Если ты читал также как читаешь форум, то считай что не читал.
0K>То же самое могу сказать про вас. Читаете между строк и только то что вам нравится. Ниже я это докажу.
Попробуй, с доказательствами у тебя как раз хреново.
G>>Да просто приведи текст и название раздела, в новой редакции найдем.
0K>Так и называется: работа с unhandled exception (отдельная статья для WinForm, WebForm и пр.).
В тертьей редакции нет, устарело наверное
G>>Перевожу
G>>
G>>Разработчики библиотек не должны даже думать о неперехваченных исключениях.
G>>Только разработчики приложений должны беспокоиться о неперехваченных исключениях,
G>>и приложение должно иметь политику обработки необработанных исключений.
G>>Microsoft рекомендует принимать политику по-умолчанию для CLR
G>>Последняя фраза таки означает что не надо писать глобальный обработчик исключений.
0K>Вот это то о чем я говорил. Первые 2 фразы вы не увидели.
0K>разработчики приложений должны беспокоиться о неперехваченных исключениях 0K>разработчики приложений должны беспокоиться о неперехваченных исключениях 0K>разработчики приложений должны беспокоиться о неперехваченных исключениях
А последнюю фразу не прочитал? Рекомендуемый способ — не делать ничего, CLR сам все сделает.
0K>Дошло? Или вы называете заботой -- оставить не вполне ясное окошко с текстом ошибки? Нафига?
См выше.
Прочитай ты уже наконец рихтера внимательно и Framework Design Guidelines, может поймешь все таки.
И уж точно прекращай себя считать умнее всех.
0K>>>Только на языках предусмотренных на сайте. Исключения для разработчиков переводить не нужно. G>>А Рихтер другого мнения. И что делать если такое исключение таки увидит пользователь?
0K>Если исключение предназначено исключительно для разработчика -- пусть лучше увидит его на английском. Глобализация, английский все в школах учат -- поймет что это вы чего-то недоработали.
Ага, будут у него попеременно "Object reference is not set..." и "Пустая последовательность..." круто!
Здравствуйте, gandjustas, Вы писали:
_FR>>>>>>Поэтому ничего страшного в том, что бы показать пользователю текст прилетевшего исключение нет: если уж програмист не знает что делать, может и пользователь сможет исправить ситуацию лучше. G>>>>>А еще лучше при этом завершить приложение\текущую операцию. _FR>>>>Зачем? Можете на вскидку сзазать, по каким причинам при вызове SqlCommand.Execute<…> может прилететь SqlException? G>>>Не могу, поэтому просто не буду обрабатывать SqlException, что приведет к завершению операции или приложения. G>>>Могу сказать только ситуацию при которой можно продолжать работу после SqlException: нарушение уникальности.
_FR>>Покажите пожалуйста алгоритм, который позволит из, например, SqlException определить, что произошло именнол нарушение уникальности. G>Внтури SqlException есть SqlError, у которого есть Number. Этот Number в точности определяет тип ошибки.
Покажите пожалуйста конкретный пример, ладно? А то как зделать знают все, но никто ничего никогда не делал
G>А еще лучше написать запрос, который не упадет в случае нарушения, а потом анализировать affected rows.
Ещё лучше — или не выдавать необдуманных фраз или признавать их неправоту, чем придумывать или советовать, что лучше. Я сам могу решать, что лучше и не авторитетом давить надо ("лучше это"), а логикой. В данном случае быть может так, что запрос пишет неизвестный мне програмист и какие могут быть в нём ошибки не неизвестно. Так следует делать даже когда "неизвестный програмист" сидит рядом (даже на том же стуле за тем же монитором что и вы) — потому что чем меньше неконтролируемых договорённостей, тем надёжнее. Контракт "запрос ни при каких обстоятельствах не завершится неудачей" не сможет обеспечить никто, даже говоря о запросе вида "SELECT @@VERSION;".
_FR>>А как же быть с другими ошибками, как то нарушение ссылочной целостности? G>А как я его могу исправить? Если внешний ключ, который вводится не вручную, а выбирается из списка в интерфейсе, вдруг оказался невалидным, то единственное что я могу сделать — сказать "ололо кто-то поменял данные и надо перезапустить операцию".
Для этого нужно определить, что же произошло. Вы представляете себе порядок числа [различных] ошибок, которые могут возникнуть при выполнении запроса? Озвучьте пожалуйста.
_FR>>>>Как нужно обработать отсутствие соединения, отсутствие процедуры, недостаток прав или какую-то проблему в самой процедуре? И почему следует закрывать приложение при этом? G>>>Как минимум прервать текущую операцию, _FR>>Можно и прервать, но это к делу не относится. G>Как раз относится.
Как же? Какая разница в контексте данного вопроса — "прервать", "оправить письмо" или "отформатировать жёсткий диск"
G>>>а в некоторых случаях и закрыть приложение (например если ошибка при старте). _FR>>А если не на старте? G>Тогда прервать операцию.
И всё? ничего не сообщая пользователю?
_FR>>Вы согласны, что коментарий
А еще лучше при этом завершить приложение\текущую операцию.
зачастую не уместен? G>Нет, это зачастую самое лучшее решение. G>не забывай что большинство exception пользователь видит если в программе явно баг.
Не могу забыть, ибо не согласен с этим.
G>А если пользователь испытывает неудобства из-за этого, то баг будет исправлен быстрее.
Например, есть широкий класс софта, который пишется для администраторов, которые, в свою очередь, достаточно опытны что бы самим принять решение об устранении ошибки и сделат этого без подробшейшей информации о том, что же там произошло, им будет ой как затруднительно.
_FR>>>>Если сеть оборвалась, то и нечего дальше работать? G>>>Да, есть другие варианты? _FR>>Конечно. G>Например?
Показать пользователю текст исключения с кнопкой ОК например и подождать что он будет делать дольше — закроет приложение и пойдёт пить чай или будет устранять — например запустит сервис, проверит, что сетевой кабель подключён и прочее.
G>>>Если ocassionaly conected приложение, то там сначала все складывается в локальную базу и подобно ошибки не будет. _FR>>А если это Excel, который замапен на некую внешнюю БД? Если он будет закрываться с необработанной ошибкой, это будет совсем не то, чего ждёт пользователь. G>Он как раз ocassionaly conected. Данные хранит локально и синхронизирует с БД.
В контексте данного обсуждения важно то, что при невозможности обновить данные эксель показывает такое вот сообщение:
что является самым верным решением — эксель понятия не имеет, как в используемой пользователем системе доступа к данным отличить попытку соеденения от чего-либо ещё (остутствует таблица, нет прав) поэтому поступает единственно верно: даёт сообщение на откуп пользователю. и не падает.
_FR>>Как и в большинстве задач. G>Нет. Как раз в большинстве задач нарушение связи с БД означает невозможность дальнейшей работы.
Во-первых, временную. Во-вторых, легко устраняемую на стороне клиента. Поэтому аварийно закрывать приложение в данном случае (а я могу придумать и сотни других) не нужно.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, gandjustas, Вы писали:
G>не забывай что большинство exception пользователь видит если в программе явно баг. А если пользователь испытывает неудобства из-за этого, то баг будет исправлен быстрее.
Да, именно это можно выделить как ключевые слова (по поему мнению). Даже если принять их на веру (мне не нравится слово "большинство") то это прямо означает, что
А еще лучше при этом завершить приложение\текущую операцию.
не верно, потому что нет уточнения про "меньшенство", которое имеет место быть в "не забывай что большинство exception …".
G>не забывай что большинство exception пользователь видит если в программе явно баг.
Тут от самого исключения очень много зависит. Если речь про NullReferenceException, ArgumentException или InvalidOperationException, то это однозначно баг. Если речь про MyBussinessLogicException, прилетевшую с сервера при выполнении сложной операции? На клиента прикажите добавлять информацию по всевозможным кодам ошибки? (С сиквелам указанная мной выше "проблема" того же разряда).
Далается же так: сервер тужится, что-то делает, не вышло — сообщает об этом. (может быть или системная или логическая ошибка, систьемную можно не показывать, я о логической). Протягивать ошибку не как исключение а как некий OperationResult накладно (суть: тот же код ошибки со всеми вытекающими и разницы некакой от исключения). Поэтому слова о том, что текст некоторых исключений более чем предназначен для глаз конечного пользователя — отображать суть. покажите-ка мне пример какого-нить аналога динк-пада, который падает при возникновении DbException
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>Здравствуйте, gandjustas, Вы писали:
_FR>>>>>>>Поэтому ничего страшного в том, что бы показать пользователю текст прилетевшего исключение нет: если уж програмист не знает что делать, может и пользователь сможет исправить ситуацию лучше. G>>>>>>А еще лучше при этом завершить приложение\текущую операцию. _FR>>>>>Зачем? Можете на вскидку сзазать, по каким причинам при вызове SqlCommand.Execute<…> может прилететь SqlException? G>>>>Не могу, поэтому просто не буду обрабатывать SqlException, что приведет к завершению операции или приложения. G>>>>Могу сказать только ситуацию при которой можно продолжать работу после SqlException: нарушение уникальности.
_FR>>>Покажите пожалуйста алгоритм, который позволит из, например, SqlException определить, что произошло именнол нарушение уникальности. G>>Внтури SqlException есть SqlError, у которого есть Number. Этот Number в точности определяет тип ошибки.
_FR>Покажите пожалуйста конкретный пример, ладно? А то как зделать знают все, но никто ничего никогда не делал \
Для SQL Server код нарушения UNIQUE CONSTRAINT — 2627
try
{
}
catch (SqlException ex)
{
var hasUnhandledErrors = false;
foreach (SqlError error in ex.Errors)
{
if (error.Number == 2627)
{
HandleError(error);
}
else
{
hasUnhandledErrors = true;
}
}
if (hasUnhandledErrors)
{
throw;
}
}
G>>А еще лучше написать запрос, который не упадет в случае нарушения, а потом анализировать affected rows.
_FR>Ещё лучше — или не выдавать необдуманных фраз или признавать их неправоту, чем придумывать или советовать, что лучше. Я сам могу решать, что лучше и не авторитетом давить надо ("лучше это"), а логикой.
Логика как раз говорит что лучше прекратит работу если вылетел неожиданный exception.
_FR>В данном случае быть может так, что запрос пишет неизвестный мне програмист и какие могут быть в нём ошибки не неизвестно.
И?
_FR>>>А как же быть с другими ошибками, как то нарушение ссылочной целостности? G>>А как я его могу исправить? Если внешний ключ, который вводится не вручную, а выбирается из списка в интерфейсе, вдруг оказался невалидным, то единственное что я могу сделать — сказать "ололо кто-то поменял данные и надо перезапустить операцию".
_FR>Для этого нужно определить, что же произошло. Вы представляете себе порядок числа [различных] ошибок, которые могут возникнуть при выполнении запроса? Озвучьте пожалуйста.
Нет, именно поэтому я не буду их обрабатывать и прерву операцию.
_FR>>>>>Как нужно обработать отсутствие соединения, отсутствие процедуры, недостаток прав или какую-то проблему в самой процедуре? И почему следует закрывать приложение при этом? G>>>>Как минимум прервать текущую операцию, _FR>>>Можно и прервать, но это к делу не относится. G>>Как раз относится.
_FR>Как же? Какая разница в контексте данного вопроса — "прервать", "оправить письмо" или "отформатировать жёсткий диск"
Большая разница. Это state mamgement и побочные действия.
G>>>>а в некоторых случаях и закрыть приложение (например если ошибка при старте). _FR>>>А если не на старте? G>>Тогда прервать операцию.
_FR>И всё? ничего не сообщая пользователю?
Конечно сообщая, я про побочные действия не говорю сейчас.
_FR>>>Вы согласны, что коментарий
А еще лучше при этом завершить приложение\текущую операцию.
зачастую не уместен? G>>Нет, это зачастую самое лучшее решение. G>>не забывай что большинство exception пользователь видит если в программе явно баг. _FR>Не могу забыть, ибо не согласен с этим.
Ну приведи пример когда это не так и это не является ошибкой проектирования.
G>>А если пользователь испытывает неудобства из-за этого, то баг будет исправлен быстрее. _FR>Например, есть широкий класс софта, который пишется для администраторов, которые, в свою очередь, достаточно опытны что бы самим принять решение об устранении ошибки и сделат этого без подробшейшей информации о том, что же там произошло, им будет ой как затруднительно.
Еще раз, я не о сообщениях говорю, а о поведении программы при exception.
Здравствуйте, _FRED_, Вы писали:
_FR>Здравствуйте, gandjustas, Вы писали:
G>>не забывай что большинство exception пользователь видит если в программе явно баг. А если пользователь испытывает неудобства из-за этого, то баг будет исправлен быстрее.
_FR>Да, именно это можно выделить как ключевые слова (по поему мнению). Даже если принять их на веру (мне не нравится слово "большинство") то это прямо означает, что
_FR>
А еще лучше при этом завершить приложение\текущую операцию.
_FR>не верно, потому что нет уточнения про "меньшенство", которое имеет место быть в "не забывай что большинство exception …".
Чем не нравятся споры про exception что они как-то сильно абстрактные, как доходит до кода, так сразу все эти теории по перехватыванию всего идут лесом.
G>>не забывай что большинство exception пользователь видит если в программе явно баг.
_FR>Тут от самого исключения очень много зависит. Если речь про NullReferenceException, ArgumentException или InvalidOperationException, то это однозначно баг. Если речь про MyBussinessLogicException, прилетевшую с сервера при выполнении сложной операции? На клиента прикажите добавлять информацию по всевозможным кодам ошибки? (С сиквелам указанная мной выше "проблема" того же разряда).
Ну ты же не будет все коды ошибок анализировать (как с бд), а если ты не обрабатываешь ошбику, то единственное что ты можешь сделать с точки зрения программной логики — откатиться к какому-либо безопасному состоянию (читай прервать операцию).
