Ключевое слово броска в подписи функции
Мнение: никогда не было разного кода между сборками "debug" и "release"
Основная причина в том, что код выпуска почти никогда не тестируется. Лучше, чтобы в тесте работал тот же код, что и в дикой природе.
4 ответа
Нет, это не считается хорошей практикой. Напротив, это обычно считается плохой идеей.
http://www.gotw.ca/publications/mill22.htm более подробно объясняет, почему, но проблема частично в том, что компилятор не может обеспечить это, поэтому его необходимо проверять во время выполнения, что обычно нежелательно. И в любом случае это плохо поддерживается. (MSVC игнорирует спецификации исключений, за исключением throw (), который интерпретируется как гарантия того, что исключение не будет создано.
Когда к языку были добавлены спецификации throw, это было сделано из лучших побуждений, но практика подтвердила более практичный подход.
В C ++ мое общее практическое правило - использовать только спецификации throw, чтобы указать, что метод не может выбросить. Это надежная гарантия. В противном случае предположим, что он может выбросить что угодно.
Единственный практический эффект спецификатора throw заключается в том, что если ваша функция выбрасывает что-то отличное от myExc , будет вызываться std :: неожиданный (вместо обычного механизма необработанных исключений).
Чтобы задокументировать типы исключений, которые может вызывать функция, я обычно делаю следующее:
bool
some_func() /* throw (myExc) */ {
}
Jalf already linked to it, but the GOTW puts it quite nicely why exception specifications are not as useful as one might hope:
int Gunc() throw(); // will throw nothing (?)
int Hunc() throw(A,B); // can only throw A or B (?)
Are the comments correct? Not quite.
Gunc()may indeed throw something, andHunc()may well throw something other than A or B! The compiler just guarantees to beat them senseless if they do… oh, and to beat your program senseless too, most of the time.
That's just what it comes down to, you probably just will end up with a call to terminate() and your program dying a quick but painful death.
The GOTWs conclusion is:
So here’s what seems to be the best advice we as a community have learned as of today:
- Moral #1: Never write an exception specification.
- Moral #2: Except possibly an empty one, but if I were you I’d avoid even that.