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

_>Ничего ясно не видно. Если функцию, бросающую исключения, писали не мы, то надо лезть в документацию (если она есть) или вообще в исходники, чтобы понять кидаются ли какие-то исключения или нет. В случае же кодов возврата (к примеру) всё сразу видно по заголовочному файлу.

Давай проверим

BOOL X();
BOOL Y();

Какой из двух методов возвращает ошибку а какой просто значение ?

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

E>>ой ли?

_>Ну во-первых если делать всё всё по правильному, то не забудь ещё реализацию своего класса исключений для данной функции... )

_>А во-вторых я на практике обычно не использую даже коды возврата — только булево значение, т.к. обычно пользователю вообще не нужно знать низкоуровневые детали. А в данном примере я написал так, чтобы никто не придрался (мол с исключениями передаётся больше информации).

Постоянно нужно получать детали — не просто невозможно открыть файл, а еще и сообщать причину — файл используется, отсутствует, не хватает прав и тд и тд. Опаньки — нужны разные коды.
Очень часто нужно перекодировать ошибки, потому что коды в каждой библиотеке свои.
Очень часто нужно сохранять вложеные ошибки.

Итого — ты просто не утруждаешь себя обработкой ошибок.

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


U>> Более интересен будет опыт таких языков как Python, где исключения с самого начала в языке и рантайме, а кодов возврата нет как таковых. Так вот в Питоне ни у кого почему-то не возникает с исключениями никаких проблем.
C>Вот уж не надо сказок. Я на досуге после миграции нашего проекта на PyPy сижу и переписываю код вида:

PyPy уже не совсем Питон.

C>В обычном Python'е он "работает" из-за того, что файловый объект детерминированно уничтожается при выходе из scope'а. А вот в PyPy уже честный GC и ВНЕЗАПНО оно как-то не очень работает.

Опаньки, GC влияет на язык. Кто бы мог подумать ?

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

U>>> Более интересен будет опыт таких языков как Python, где исключения с самого начала в языке и рантайме, а кодов возврата нет как таковых. Так вот в Питоне ни у кого почему-то не возникает с исключениями никаких проблем.
C>>Вот уж не надо сказок. Я на досуге после миграции нашего проекта на PyPy сижу и переписываю код вида:
I>PyPy уже не совсем Питон.
"PyPy is a fast, compliant alternative implementation of the Python language (2.7.8 and 3.2.5). It has several advantages and distinct features..." (c) http://pypy.org/

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

C>>Давно не хватает, на самом деле, принципиальных языков. В С++ был принцип "не платить за то, что не используется" — это стало сущесвенным стимулом в развитии.
U>Сравни принцип "не платить за то, что не используется" с "исключений не будет, потому что принцип". Какой-то один из них высосан из пальца.
Принцип у них другой: "Минимум магии и максимальная надёжность".

U>Если честно, то мне нечего сказать людям, которые не хотят учиться. Говнокодеров полно, и ничего с этим не поделать.
Если инструмент крив до неюзабельности, то это проблемы уже инструмента.

C>>В обычном Python'е он "работает" из-за того, что файловый объект детерминированно уничтожается при выходе из scope'а. А вот в PyPy уже честный GC и ВНЕЗАПНО оно как-то не очень работает.
U>Это отношение к исключениям не имеет. Тут эффект одинаковый вылетит исключение или нет.
Это к вопросу о деструкторах.

C>>Но и это фигня. Например, надо поймать исключение о нарушении констрейнта внешнего ключа. С трёх раз догадайтесь как это правильно сделать.
U>Почитать документацию, и из IntegrityError извлечь pgcode?
Авотнатрибуквы. Оно кидает разные классы из разных драйверов БД, так что официальная рекомендация — делать regex match по строке с деталями ошибки.

U>Какое отношение косяки каких-то API имеют к существу вопроса? Я могу какое угодно кривое API придумать, но это не значит, что используемый язык или идиомы кривы. Это всего лишь значит, что я придумал кривое API.
Это к вопросу об удобстве исключений.

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

I>Давай проверим

I>

I>BOOL X();
I>BOOL Y();
I>

I>Какой из двух методов возвращает ошибку а какой просто значение ?

Это в твоих проектах такие имена функций обычно, да? )))

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

I>Итого — ты просто не утруждаешь себя обработкой ошибок.

Просто я её делаю в пределах не больших, чем то, что реально требуется для показа пользователю, а не в пределах всей доступной мне изнутри информации.

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

I>>

I>>BOOL X();
I>>BOOL Y();
I>>

I>>Какой из двух методов возвращает ошибку а какой просто значение ?

_>Это в твоих проектах такие имена функций обычно, да? )))

Намекаешь, что не в состоянии провести заявленое различие ?

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

I>>Итого — ты просто не утруждаешь себя обработкой ошибок.

_>Просто я её делаю в пределах не больших, чем то, что реально требуется для показа пользователю, а не в пределах всей доступной мне изнутри информации.

Да, я в курсе, и проектируешь все проекты на сто лет вперёд, учитывая все возможные и невозможные изменения требований, а так же учитываешь все случаи реюзания твоего кода всеми возможными и невозможными способами.

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

U>Если честно, то мне нечего сказать людям, которые не хотят учиться. Говнокодеров полно, и ничего с этим не поделать.

Есть мнение, что имеет смысл учиться не синтаксису, а более важным вещам — времени всего 24 часа.

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

C>У деструктора есть магические силы, позволяющие ему избегать ошибок в close()?

Деструктор вынужден игнорировать ошибку в close. В результате из деструктора невозможно сообщить об ошибке. Поэтому все операции, которые могут закончиться с ошибкой надо делать до вызова деструктора. Я же говорю, посмотри в код практически любой библиотеки. Там так и будет.

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

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

C>>>Я подобный подход и в С++ использовал.
U>>Подкинь ссылочку? Интересно посмотреть.
C>Лень искать, что-то типа такого:
C>

C>void some_method()
C>{
C>    try {
C>        do_something(); //throws my_error
C>    } catch(...) {
C>        filter_exceptions();
C>    }
C>}

C>void filter_exceptions()
C>{
C>    try
C>    {
C>       throw;
C>    } catch(const my_exception &my)
C>    {
C>       throw another_exception(my, "blah");
C>    } catch(const std::exception &s)
C>    {
C>       throw another_exception(s, "blah2");
C>    } 
C>//....
C>}

C>

С этим я знаком. Спасибо.

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

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

U>>Всё ясно видно: обработка ошибок делегируется на уровень выше. Абсолютно одинаково с кодом на расте, только там делегирование надо производить явно. С исключениями надо привыкнуть к одному лишь правилу, что если нет обработки на данном уровне, то она делегируется на уровень выше.

_>Ничего ясно не видно. Если функцию, бросающую исключения, писали не мы, то надо лезть в документацию (если она есть) или вообще в исходники, чтобы понять кидаются ли какие-то исключения или нет. В случае же кодов возврата (к примеру) всё сразу видно по заголовочному файлу.

Ни в какие исходники лезть не надо. Это ещё одно твоё заблуждение. Ты можешь считать, что всегда возможен выброс исключения из функции, если она не объявлена noexcept(true), throw() или extern "C".

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

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

U>>Если честно, то мне нечего сказать людям, которые не хотят учиться. Говнокодеров полно, и ничего с этим не поделать.

I>Есть мнение, что имеет смысл учиться не синтаксису, а более важным вещам — времени всего 24 часа.

В обсуждаемом вопросе синтаксиса практически нет. Здесь дело в непонимании самой концепции. А синтаксис, какой бы он не был, стоит просто запомнить. Это часть профессии.

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

J>Я тоже так пишу. Саттер/Абрахамс в свое время прочистили мозги на этот счет.
J>Надо только помнить, что есть 3 уровня безопасности по исключениям.

Вот именно, что нужно помнить, понимать... То, что при использовании кодов возврата или паттерна "null object" вылезает явно, здесь припрятано — как я люблю повторять, тот же бег, по тем же граблям, только их еще заботливо присыпали сенцом, чтобы не смущать бегущих.

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

U>>Сравни принцип "не платить за то, что не используется" с "исключений не будет, потому что принцип". Какой-то один из них высосан из пальца.
C>Принцип у них другой: "Минимум магии и максимальная надёжность".

А в результате что мы получаем? Куча магии вроде try!, ?, throws (плюс монады на кривом уровне, это вам всё-таки не Хаскель). К этой магии прилагается ещё и инструкция как пользоваться на хрен знает сколько страниц. Ну и соответственно, чем сложнее механизм и чем больше магии он требует, тем меньше его надёжность. Так что я думаю, они здесь проиграли.

PS: не всё так гладко в датском королевстве (народ хочет try/catch):
http://discuss.rust-lang.org/t/crazy-exception-like-constructs-for-result/587
http://discuss.rust-lang.org/t/maybe-better-nicer-error-handling/756
https://github.com/rust-lang/rfcs/pull/243

PSS: Language-integrated Result monad (a.k.a. <b>checked exceptions</b>)
Checked exceptions — где то это уже было. Не подскажите где?

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

U>PSS: Language-integrated Result monad (a.k.a. <b>checked exceptions</b>)
U>Checked exceptions — где то это уже было. Не подскажите где?
В Java. Вполне неплохо было бы даже, если бы уроды из Sun знали как сделать нормальный язык.

Я не очень хочу неявных исключений, но если всё же их делать, то модель с Result'ом, который автоматически может превращаться в исключение — мне больше всего нравится.

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

_>>Это в твоих проектах такие имена функций обычно, да? )))
I>Намекаешь, что не в состоянии провести заявленое различие ?
Очевидно, что метод вот такой: "fn Y() -> Result<BOOL, Error> "

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

U>Деструктор вынужден игнорировать ошибку в close. В результате из деструктора невозможно сообщить об ошибке. Поэтому все операции, которые могут закончиться с ошибкой надо делать до вызова деструктора.
Второй вопрос, как быть с RAII-кодом, в котором в деструкторах огромное количество логики?

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

U>Деструктор вынужден игнорировать ошибку в close. В результате из деструктора невозможно сообщить об ошибке. Поэтому все операции, которые могут закончиться с ошибкой надо делать до вызова деструктора.

А как же RAII?