Есть класс (допустим выполняющий операции с БД). Есть методы в них может произойти исключительная ситуация... допустим при выполнения sql команды .... надо его обработать на более высоком уровне чем этот метод, да и текст по культурней вывести ... то есть я думаю надо так



Я правильно написал ... просто визуалки рядом нет... не могу проверить! 

 

Хоббит, не так, а вот так:

 

Отрывать руки и не приклеивать! Обязательно надо делать свитчи на разные типы исключений, иначе - совать его в InnerException. А то неизвестно - у тебя полетело исключение потому что SQL неправильный или потому что где-то что-то не кастуется.

Вот так:


 

З.Ы. могу только проконстатировать, что при постоянном использовании оператора trrow в своих приложениях, производительность серьёзно падает... Это действительно так. 

P.S. Лично мне нравится свитч из Немерле:

Код

в коде try {   Connect(); } catch {    | e : МоёИсключение => ...    | e : ТвоёИсключение => ...    | _ => Console.WriteLine("Что-то другое") }

 

Поделитесь пожалуйста мыслями, чем обработка исключений(при помощи встроенных классов исключений или написанных программистом) лучше чем обыкновенные проверки в if'ах.
Например есть класс Queue и в нем имеется функция get(). В функции надо обработать ситуацию когда пользователь пытается получить из пустой очереди какую то инфу.
1-ый вариант обработки возможной ошибки

2-ой вариант обработки возможной ошибки
очень хотелось бы услышать от опытных людей всегда ли стоит использовать обработку исключений при помощи try / catch / throw, т.к. прога из-за таких обработок оооооооочень тормозит.

Все зависит от:
1) умеет ли класс, использующий твой метод (get -- тоже метод) правильно распознать произошла ошибка или нет.
В твоем случае это Console.WriteLine(" - The Queue is empty.") что вообще никто не словит (если сильно не захочет) и возврат нуля (который теперь исключен из допустимых символов).
2) кто должен отвечать за правильность данных. Тот кто вызывает либо тот кого вызывают. Если первый, то логичнее (и универсальнее) использовать throw (на случай если "профессор--лопух"), если нет, то возможно обработать исключение более мягко и уведомить вызывающий код задокументированным способом.
3) критично ли эта операция. Если это юзверьинтерфейс, то человек особо не заметит задержки произошедшей по вине throw (зато ошибаться будет часто). Если же это автоматическая обработка большого объема данных (даже если не большего), то нужно избежать как можно большего количества throw
4) может кто-нить еще добавит что-нить

ИМХО

ну это не проблема, а просто пример =), в жизни можно сделать errflag например ну и задавать ему true если произошла ошибка.

Спасибо за ответ   , получила пищу для мыслительного процесса   


Это сообщение отредактировал(а) agl - 3.11.2006, 00:44

mr.DUDA, а что ты имеешь ввиду под использованием throw? я вот просто подумываю, что будет работать быстрее:
ты имеешь ввиду заключение кода в try...catch ухудшает быстродействие? или непосредственное исполнение оператора throw ухудшает бытродействие?

archimed7592, непосредственное развертывание стека и поиск оператора который этот throw словит --- вот что замедляет быстродействие

Ну попробуй. Я, например, такого исследования не проводил. 
Хотя, на вскидку, ---- второй будет быстрее, ведь он словит эксэпшен в первом блоке, а в остальные даже не пойдет   

Генерация исключения (всё что происходит при этом - упаковка stack trace,  и поиск подходящего блока catch) - оверхед, и если злоупотреблять оператором throw, то в худшем случае оверхед может и до десятка процентов дорасти. Простой пример, без вложенных try..catch:



Я не говорю, что исключения не нужно обрабатывать и детализировать, это ересь; но пользоваться ими там, где можно было бы обойтись без генерации исключения - плохая практика.