Re[3]: Спецификация исключений - C/C++

Здравствуйте, Duncan MacLeod, Вы писали:

DM>Речь идет не о намеренном несоответствии комментариев коду, а о том, что поддерживать код и комментарии в строгом соответствии при таком подходе очень сложно.
Да, я вас понял. Но у нас, например, тот кто изменяет код, сопровождаемый комментариями, отвечает за "актуальность" комментариев.
А вобще, вспомнилась глава из Страуструппа про комментарии

Так вот он там пишет, что не соответствующие действительности комментарии — это еще хуже чем их отсутствие

Думается он очень прав

Так что изменение откомментированного кода, без изменения соответствующих комментариев — очень плохой стиль.
А если возвращаться к первоначальному вопросу — то вопрос был, "как лучше писать, что бы код был легко поддерживаемым", я и высказал свою тз на вопрос. А дальше пошел вопрос "как лучше писать, что бы не смогли сломать". имхо если нет единых правил и требований к написанию, и внесению изменений изменений в уже написанный код — сломают все-равно.

Здравствуйте, Аноним, Вы писали:

А>Егог, вот как я обычно делаю:

А>

А>class MyDataProcessor {
А>public:
А>      // У каждого класса индивидуальный тип исключений, производный от базового
А>   class DPError : public ::x_Ception {
А>      // тут чего-то ещё
А>   };
А>};
А>

Это всё я понял, просто я nested класс иключения назвал x_Ception. По идее можно, а код легко переиспользовать зато.

А>

А>// непосредственный клиент. не очень высокий уровень
А>bool CompareData( const MyDataProcessor &left, const MyDataProcessor &right )
А>{
А>    // Пытаемся обработать в этом контексте
А>    try {
А>        return left.GetDataQuility() < right.left.GetDataQuility();
А>    } catch( MyDataProcessor::DPError& e ) {// Какие исключения тут ждать? 
А>        // тут обработка
А>    }
А>}
А>

А зачем так делать? Если параметры не те, что какая тут обработка? А если там что-то нетривильное предполагается, то почему бы логику не написать явно?

Ну типа там, положим мы хотим вводить данные пока они не станут корректными, ну так и пишем:

MyData data;
do {
    data.AskFromUser();
} while( !dataProc.IsCorrect( data ) );
dataProc.ProcessData( data );

Казалось бы так намного прямее...

А>

А>// Где-то на самом верху
А>    try {
А>          // вызов функции (мы не знаем, что она сгенерит, но полюбому что-то производное от x_Ception) 
А>          call_method();   
А>        } catch( x_Ception& e ) 
А>       {
А>        // тут обработка
А>       }
А>

А>все это нужно, чтобы на относительно низком уровне можно было идентифицировать источник исключения.
А>Тогда как на самом верху мы будем ловить базовый класс.

А зачем его идентифицировать? Обычно надо не источник идентифицировать а какую-то конкретную проблему. И для неё можно использовать какое-то конкретное решение. А в общем случае не ясно зачем идентифицировать источник. А если источник не сам класс, а используемый им класс?

Здравствуйте, dip_2000, Вы писали:

_>Да, я вас понял. Но у нас, например, тот кто изменяет код, сопровождаемый комментариями, отвечает за "актуальность" комментариев.
Да просто при таком подходе то, какие исключения стоит ждать из функции зависит от реализации самой функции и всего того, что она при реализации использует.

То есть при любом изменении может понадобится переписать почти все комментарии.

Вот представь, что ты решил использовать новый аллокатор в перекрытом operator new, скажем...

E>Ну обычно программы всё-таки в основном работают, а не исключения обрабатывают. Так что от системы исключений требуется продуманность, простота, и надёжность.
E>Зачем в каждом классе заводить своё исключение?
Java-style

Не подумайте что я ругаю джаву — просто обычно так пишут люди, которые какое-то время писАли на Java а потом вернулись (или пересели) на С++. Дело в том что при внешней схожести спецификации исключений в Java и C++ ведут себя очень сильно по-разному.

... << RSDN@Home 1.2.0 alpha rev. 717>>

S>Спасибо всем, за советы. Я просто закомментировал спецификацию исключений: // throw(Error)
S>Просто мне нужно было документировать каждый метод на предмет генерирования исключений. Проект уже большой и начинаешь забывать что генерит какая функция. Все типы исключений в проекте унаследованы от одного базового класса. А каждый класс создает свой тип исключений, наследник базового (это вложенный класс). И когда один класс имеет поля другого класса, а другой третьего, и т. д. в конечном счете класс верхнего уровня генерит много типов исключений. Но все они имеют общий базовый тип.
S>Как вы считаете, такой подход хорошь, или есть что то лучше?

Кстати, а зачем вызывающему коду знать какие именно исключения может бросать функция?

... << RSDN@Home 1.2.0 alpha rev. 717>>

Здравствуйте, Left2, Вы писали:

L>Кстати, а зачем вызывающему коду знать какие именно исключения может бросать функция?

Ну, напрмиер, чтобы их все перекрыть..

L>>Кстати, а зачем вызывающему коду знать какие именно исключения может бросать функция?

E>Ну, напрмиер, чтобы их все перекрыть..

Э... catch(...) (а потом (обязательно!) — throw()). Но это всё равно имхо хыбна практика (кроме случая когда исключения не могут проходить через границы нашей функции). Перехватывать нужно те исключения, которые можешь обработать, а не те которые может швырнуть вызываемый код.

... << RSDN@Home 1.2.0 alpha rev. 717>>

Здравствуйте, Left2, Вы писали:

L>>>Кстати, а зачем вызывающему коду знать какие именно исключения может бросать функция?
E>>Ну, напрмиер, чтобы их все перекрыть..

L>Перехватывать нужно те исключения, которые можешь обработать, а не те которые может швырнуть вызываемый код.

Понятие "обработать" включает в себя также преобразование пойманного исключения в свое, возможно с добавлением контекстной информации.

Здравствуйте, Left2, Вы писали:

E>>Ну, напрмиер, чтобы их все перекрыть..

L>Э... catch(...) (а потом (обязательно!) — throw()). Но это всё равно имхо хыбна практика (кроме случая когда исключения не могут проходить через границы нашей функции). Перехватывать нужно те исключения, которые можешь обработать, а не те которые может швырнуть вызываемый код.

Ну вот поэтому catch(...) Не годится...
Чтобы перекрыть иключения и как-то осмысленно обработать нужен их список...

Здравствуйте, Erop, Вы писали:

_>>Да, я вас понял. Но у нас, например, тот кто изменяет код, сопровождаемый комментариями, отвечает за "актуальность" комментариев.
E>Да просто при таком подходе то, какие исключения стоит ждать из функции зависит от реализации самой функции и всего того, что она при реализации использует.
E>То есть при любом изменении может понадобится переписать почти все комментарии.
А какие есть альтернативы ? Я понимаю проблемму, о которой вы говорите, я согласен, что она существует, но какие альтернативы ? Явно указывать спецификацию исключений с помощью средств языка ? Писать не документированный код ?

E>Вот представь, что ты решил использовать новый аллокатор в перекрытом operator new, скажем...
Не ежедневная операция

Здравствуйте, dip_2000, Вы писали:

_>А какие есть альтернативы ? Я понимаю проблемму, о которой вы говорите, я согласен, что она существует, но какие альтернативы ? Явно указывать спецификацию исключений с помощью средств языка ? Писать не документированный код ?

Ну, возможно, писать в комментариях дату последней проверки их валидности

Или считать что везде может пролететь x_Ception, или ещё как. Я так понимаю, что ты спрашиваешь в реалиях обсуждаемого проекта?

Ясно, что последовательный подход состоит в том, что надо перейти на нормальную систему исключений. Но это может быть очень дорого. Возможно её можно как-то регуляризировать, например. Или можно как-то переходить постепенно, или ещё чего можно. Не видя проекта не скажешь

	От:	dip_2000
	Дата:	29.11.07 09:53
	Оценка:	+1

	От:	Erop
	Дата:	30.11.07 13:17
	Оценка:	+1

	От:	Erop
	Дата:	30.11.07 13:20
	Оценка:

	От:	Left2
	Дата:	30.11.07 13:37
	Оценка:

	От:	Left2
	Дата:	30.11.07 13:45
	Оценка:

От:	Андрей Коростелев	http://www.korostelev.net/
Дата:	30.11.07 16:43
Оценка:	+1