Здравствуйте, Undying, Вы писали:
U>В приведенном коде в общем catch'е есть осмысленная стратегия — это логгирование в виде Console.WriteLine("Не удалось распарсить HTML"). Вышестоящий код не знает, что ошибка состоит в том, что "Не удалось распарсить HTML", соответственно без catch (Exception ex) тут никак не обойтись.
Приведенный код вообще не уведомляет вышестоящий код об ошибке.
Он просто втихую саботирует, против чего собственно guide по неперехвату System.Exception и пытается бороться.
Здравствуйте, midcyber, Вы писали:
M>Здравствуйте, Undying, Вы писали:
U>>В приведенном коде в общем catch'е есть осмысленная стратегия — это логгирование в виде Console.WriteLine("Не удалось распарсить HTML"). Вышестоящий код не знает, что ошибка состоит в том, что "Не удалось распарсить HTML", соответственно без catch (Exception ex) тут никак не обойтись.
M>Приведенный код вообще не уведомляет вышестоящий код об ошибке. M>Он просто втихую саботирует, против чего собственно guide по неперехвату System.Exception и пытается бороться.
Ну во всяком случае автор не указывал, что этот код является каким-либо подуровнем. С чего вы взяли, что это не вышестоящий код?
На какой уровень поднимать исключения это уже другой вопрос.
Здравствуйте, midcyber, Вы писали:
M>Приведенный код вообще не уведомляет вышестоящий код об ошибке. M>Он просто втихую саботирует, против чего собственно guide по неперехвату System.Exception и пытается бороться.
А вопрос почитать, который автор топика задавал? Автор топика спрашивал нужно ли всегда писать специальную обработку каждого типа исключения и нужно ли писать обработчик непредвиденных типов исключений. Автор топика не спрашивал о том, что должно быть внутри catch'а, соответственно понятно, что внутри catch написана заглушка, просто для иллюстрации идеи. Если тебе эта заглушка не нравится напиши это автору топика, т.к. если она неправильная, то косяк будет и в первом варианте обработки исключений, и во втором.
Здравствуйте, 0K, Вы писали:
0K>Пользователь указывает html (пусть в виде строки). Нужно проверить на корректность. Специального метода нет, но есть библиотека которая его парсит. Какой вариант проверки правильный:
0K>Вариант 1
0K>Вариант 2 0K>
В обоих подходах плохо то, что мы игнорируем текст исключения. А он может сказать о многом.
Можно сделать так:
try
{
doc.LoadHtml(html);
}
catch (Exception ex)
{
// Приводим класс в целостное состояние
...
// Обёртываем исключение, добавив понятный клиенту текст. throw new HtmlDocumentException("Не удалось распарсить HTML.", ex);
}
Теперь в вызывающем коде верхнего уровня мы сможем показать пользователю культурное сообщение ("Не удалось распарсить HTML.") плюс по кнопочке "Подробнее" — показать текст внутреннего исключения (обычно это жутко выглядящий, но крайне полезный для опытного глаза набор строк).
Здравствуйте, 0K, Вы писали:
0K>Здравствуйте, midcyber, Вы писали:
M>>Да, внешне будут "рюшечки" — никогда не падающая программа. M>>Возможно, показывающая пользователю пустое окно вместо данных. Возможно, некорректные данные, что еще хуже.
0K>А как в данном случае тип исключения может повлиять на появление пустого окна или некорректные данные? Вы видите хоть один вариант.
Существует три типа эксепшенов, которые могут возникнуть в любой момент при том, что ваш код может быть корректным (а вот чужой вызываемый — нет): переполнение стека, отсутствие памяти и ошибка рантайма.
Их можно проигнорировать, но последствия могут быть непредсказуемые для пользователя и его данных.
Ты говорил как-то, что мы тут не медицинский софт пишем, но я лучше потеряю полчаса работы в ворде, когда он закроется, чем весь документ, когда он мне его радосно перезатрет и скажет, что все ОК.
M>>Так и зачем их вообще тут перехватывать, если нет осмысленных стратегий? M>>Почему не передать выше, пусть разбирается тот, у кого они есть U>В приведенном коде в общем catch'е есть осмысленная стратегия — это логгирование в виде Console.WriteLine("Не удалось распарсить HTML").
О, логирование ja ja , а потом кто-то видя это добавляет сюда валидацию или ещё что и пошло поехало.
А послезавтра мы захотели Log4net
В приведённом тобой варианте 3 дублирования не меньше.
1. Почему ты перехватил ArgumentException, FormatException, IndexOutOfRangeException и InvalidOperationException, а деление на ноль пропустил?
2. Почему у тебя на каждое перехваченное исключение реакция одна и та же? А если нет разницы, то что называется "только программист мог дать такой верный, но абсолютно бесполезный ответ"?
Использовать враппер для работы со сторонней библиотекой хорошая идея. Использовать в этом же враппере враппер для исключений — тоже хорошая идея. Но автор темы спрашивал не про это.
Автор темы выбрал довольно интересный пример, чтобы показать, что стандарты надо применять сознательно, ибо они хоть и придуманы людьми для людей, но не являются догмой.
Обрати внимание на то, сколько сейчас в dotnet активных тем этого автора, и все они про работу с исключениями.
Здравствуйте, akasoft, Вы писали:
A>Здравствуйте, samius, Вы писали:
S>>Количество активных тем — не есть признак компетенции автора в вопросе.
A>Не есть. Но признак желания автора в этом вопросе разобраться.
Только то, чем он занимается в этих темах — сложно классифицировать как попытку разобраться. Его посты полны недоумения, почему остальные с ним спорят и не понимают очевидных для него вещей. Вот лет через 7 все поумнеют, тогда можно будет продолжить.
Здравствуйте, akasoft, Вы писали:
A>Здравствуйте, samius, Вы писали:
S>>Количество активных тем — не есть признак компетенции автора в вопросе.
A>Не есть. Но признак желания автора в этом вопросе разобраться.
Скорее признак желания навязать сообществу свои воззрения. Иногда интересные, а иногда и нет.
Здравствуйте, SE, Вы писали:
SE>Существует три типа эксепшенов, которые могут возникнуть в любой момент при том, что ваш код может быть корректным (а вот чужой вызываемый — нет): переполнение стека, отсутствие памяти и ошибка рантайма. SE>Их можно проигнорировать, но последствия могут быть непредсказуемые для пользователя и его данных.
И действительно. Это системные исключения. Если бы иерархия исключений была структуризирована по моей концепции -- таких проблемы бы не было.
Здравствуйте, SE, Вы писали:
SE>Ты говорил как-то, что мы тут не медицинский софт пишем, но я лучше потеряю полчаса работы в ворде, когда он закроется, чем весь документ, когда он мне его радосно перезатрет и скажет, что все ОК.
