Re[27]: Checked exceptions... зло или добро?
От: Павел Кузнецов  
Дата: 20.07.05 18:34
Оценка: :)
IT,

> ПК> Дык, никак не решаю. Как раз в случае NNTP и напрягает помечать...


> А я для себя решил Прикрутил к янусу MS SQL, базу поставил на рабочий лаптоп и готово. Прихожу домой, янус на лаптопе вырубаю, на домашней машине врубаю. Домашняя машина использует базу, которая на лаптопе. Сказка


Интересный вариант... Только, боюсь, в моем случае не прокатит: у меня три машины (десктопы в офисе и дома, плюс лаптоп). Лаптоп ношу не всегда. Но мысль очень интересная... В общем, как соберусь с духом, опять в Янус полезу, наверное... "Ежики кололись, плакали, но лезли на кактус"
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[20]: Checked exceptions... зло или добро?
От: dshe  
Дата: 20.07.05 19:53
Оценка:
Здравствуйте, IT, Вы писали:

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


IT>>>Не пугай меня. Это называется строить логику программы на исключениях. Объектно-ориентированный longjump. Никакого отношения к надёжности программы это не имеет.


BKV>>Да ладно тебе — ты сам на таком проекте работаешь и до этого работал


IT>Знакомьтесь, Борис KV За время своей работы на посту тим. лида в IBM успел уволить с проекта двух американов и двух индусов, одного архитектора разжаловать в девелоперы, одного перевести с "повышением" в другой тим. В общем, добрейшей души человек. Вот только логику на эксепшинах и Object Oriented LongJump так и не сумел искоренить!!!


Что именно плохого в простроении логики программы на исключениях (прикладных)? Серьезно.
--
Дмитро
Re[21]: Checked exceptions... зло или добро?
От: Павел Кузнецов  
Дата: 20.07.05 19:56
Оценка: 4 (1) +3
dshe,

> Что именно плохого в простроении логики программы на исключениях (прикладных)? Серьезно.


При широком использовании — неочевидность (неявность) связей и взаимодействия, с вытекающей сложностью в сопровождении.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[21]: Checked exceptions... зло или добро?
От: IT Россия linq2db.com
Дата: 20.07.05 21:37
Оценка: 8 (3) +11 -1
Здравствуйте, dshe, Вы писали:

D>Что именно плохого в простроении логики программы на исключениях (прикладных)? Серьезно.


Кроме того что упомянул Павел (неочевидность кода) можно добавить ещё то, что в больших количествах исключения существенно подтормаживают скорость выполнения приложения.

Но это всё меркнет по сравнению с одной фичей, которая по моему мнению находится в одном ряду с такими вещами как IntelliSense. Я имею ввиду Debug -> Exceptions -> Break into the debugger. Я это дело включаю всегда и на поиск 99% багов у меня уходит ровно 0 минут 0 секунд. Просто запускаешь приложение, выполняешь сценарий и в случае нештатной ситуации отладчик останавливается там, где произошло исключение. Помнится в 6-й студии была такая штука как break point с условием, работало, но изрядно подтормаживало. Даже был такой вопрос в MCSD треке типа как остановиться на 19874-й итерации цикла чтобы посмотреть что там происходит. Ничего этого теперь не нужно. Просто запускай приложение и жди.

Но есть одно но, которое часто омрачает такую сказочную жизнь. Это любители логики на исключениях. Если приложение кидает исключения налево и направо, то эту фичу приходится отключать и ловить ошибку что называется вручную, применяя старые дедовские методы. А на это уже уходит больше чем 0 секунд и даже на много больше чем 0 минут. Я человек ленивый и всё это меня ужасно раздражает и выводит из себя

Так же замечено, что логикой на исключениях часто замазываются дыры толи по незнанию, толи по халатности. Начиная разбираться в конкретной ситуации чаще всего оказывается, что проблема решается более простыми и честными методами, а то и вообще try/catch просто используется для обхода бага, который надо исправить, а не замазывать.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[20]: Checked exceptions... зло или добро?
От: BorisKV  
Дата: 20.07.05 23:02
Оценка:
Здравствуйте, IT, Вы писали:

BKV>>Да ладно тебе — ты сам на таком проекте работаешь и до этого работал


IT>Знакомьтесь, Борис KV За время своей работы на посту тим. лида в IBM успел уволить с проекта двух американов и двух индусов, одного архитектора разжаловать в девелоперы, одного перевести с "повышением" в другой тим. В общем, добрейшей души человек. Вот только логику на эксепшинах и Object Oriented LongJump так и не сумел искоренить!!!


Ладно тебе прикалываться — я на самом деле добрейшей души человек — особенно как водки выпью — Amicore летает — ну вернее летает то что мы писали и туда же переводят остальную часть приложения. И небыло у нас там логики на исключениях. А для всего остального мы ввели Abstraction Layers Включая текущий проект. И опять же недалее как сегодня, отбил на совещании что на Ослика мы забиваем и наш тим спокойно будет делать Японию без его "солюшинов" — но это вообще дикий оффтоп.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[19]: Checked exceptions... зло или добро?
От: Шахтер Интернет  
Дата: 20.07.05 23:15
Оценка: :)
Здравствуйте, Cyberax, Вы писали:

C>Andrei N.Sobchuck wrote:


>>>> Намекну тебе, что ты сейчас общашся с одним из авторов этого сайта

>> C>А RSDN.NNTP не ты писал, случайно?
>> А ты спрашиваеш с добрыми намерениями или со злыми?

C>С добрыми, с добрыми. Хочу помочь человеку научится летать — с 9 этажа.


C>--

C>С уважением,
C> Alex Besogonov (alexy@izh.com)

Подари ему лопату -- пусть копает побольше.
В XXI век с CCore.
Копай Нео, копай -- летать научишься. © Matrix. Парадоксы
Re[23]: Checked exceptions... зло или добро?
От: Шахтер Интернет  
Дата: 20.07.05 23:45
Оценка: 81 (2) +5
Здравствуйте, eao197, Вы писали:

Внесу свои пять копеек в вашу с Павлом совместную диссертацию.

E>Что мне еще не понравилось в обсуждении в с++.moderated, так это то, что там чуствуется некая вера в то, что программы могут быть полностью отлаженными.


На самом деле, может быть. Практика показывет, что даже при явном недостатке средств для статического анализа кода применение правильной комбинации существующих приёмов программирования и тестирования позволяет достичь очень высокого качества кода. Основная причина низкого качества кода вовсе не в слабости технологий программирования (которая конечно имеет место быть), а в низкой квалификации массового программиста и в банальной недобросовестности. 99% дефектов в софте возникают именно по этой причине.

E>И если появляется какая-то ошибка (некорректные аргументы для метода), то это от недостаточности тестирования. Поэтому вместо продолжения работы лучше с фанфарами грохнуться в core dump. Это напоминает веру в то, что статическая типизация или достаточное unit/regression/integration-тестирование способно повысить качество ПО. Имхо, сложность в том, что ошибки есть и будут в отлаженных программах всегда. И что кроме повышения объема и качества тестирования до запуска приложения в эксплуатацию нужно еще заботится о том, чтобы программа была способна выживать в условиях проявления необнаруженных ранее ошибок (об этом речь заходила в Re[23]: Что толку в Ада если Ариан 5 все равно упал
Автор: А почему вы спрашиваете
Дата: 22.06.05
):

E>

E>Очень интересно, что все участники дискуссии полностью проигнорировали этот фрагмент отчета. Собственно, ничего удивительного в этом нет, это типичное заблуждение, которое заключается в том, что ПО можно сделать свободным от дефектов и предусматривать какие-то меры восстановления от программных сбоев нет необходимости. И это-то при том, что именно программные ошибки занимают второе место среди причин отказов информационных систем (первое место — cockpit failure), а аппаратные сбои только на третьем.

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



Это хорошая мысль.

E>Ссылка по теме: диссертация Joe Armstrong'а на тему "Making reliable distributed systems in the presence of software errors" (http://www.sics.se/~joe/thesis/armstrong_thesis_2003.pdf)



E>Если проводить аналогию с живыми организмами, то сваливание в core dump при обнаружении нарушения предусловия напоминает насильственное лишение жизни после ампутации конечности. Хотя жизнь показывает, то даже с очень большим числом повреждений организм вполне способен жить.


Это правда. Как показывает опыт, софт действительно обладает определённым запасом выживаемости, как это ни странно.
В XXI век с CCore.
Копай Нео, копай -- летать научишься. © Matrix. Парадоксы
Re[24]: Чтобы не быть голословным.
От: Шахтер Интернет  
Дата: 21.07.05 03:11
Оценка: 1 (1) +4
Здравствуйте, Шахтер, Вы писали:

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


Ш>Внесу свои пять копеек в вашу с Павлом совместную диссертацию.


E>>Что мне еще не понравилось в обсуждении в с++.moderated, так это то, что там чуствуется некая вера в то, что программы могут быть полностью отлаженными.


Ш>На самом деле, может быть. Практика показывет, что даже при явном недостатке средств для статического анализа кода применение правильной комбинации существующих приёмов программирования и тестирования позволяет достичь очень высокого качества кода. Основная причина низкого качества кода вовсе не в слабости технологий программирования (которая конечно имеет место быть), а в низкой квалификации массового программиста и в банальной недобросовестности. 99% дефектов в софте возникают именно по этой причине.


Вот банальный пример, который сегодня мне попался на глаза. Ниже идет фрагмент кода операционной системы vxWorks.


int ftpCommandEnhanced
    (
    int ctrlSock,       /* fd of control connection socket */
    char *fmt,          /* format string of command to send */
    int arg1,           /* first of six args to format string */
    int arg2,
    int arg3,
    int arg4,
    int arg5,
    int arg6,
    char *replyString, /* storage for the last line of the server response or NULL */
    int replyStringLength  /* Maximum character length of the replyString */
    )
    {
    char buffer [128];
    int len;

    if (ftplDebug & FTPL_DEBUG_OUTGOING)
        {
        printErr ("---> ");
        printErr (fmt, arg1, arg2, arg3, arg4, arg5, arg6);
        printErr ("\n");
        }

    /* Format Command to send to FTP server */

    /* The next line will generate a warning with gcc 2.96+, this is O.K. */
    sprintf (buffer, fmt, arg1, arg2, arg3, arg4, arg5, arg6);    len = strlen(buffer);

    /* Append CR LF to format copy to force a single write to TCP */

    sprintf(&buffer[len],"%s","\r\n");
    len = strlen(buffer);


Данный код используется для отправки команд на FTP сервер.
Включая такие команды как STOR <имя файла>.

Я думаю, не надо напоминать, что длина имени файла может быть очень большой (больше 128 символов в Виндах).
Дефект, показанный в коде выше нельзя назвать случайной ошибкой. Это или недомыслие, или разгильдяйство.
Вот от такого разгильдяйства возникают проблемы на космических аппаратах. И в других дорогих и важных системах.
В XXI век с CCore.
Копай Нео, копай -- летать научишься. © Matrix. Парадоксы
Re[21]: Checked exceptions... зло или добро?
От: IT Россия linq2db.com
Дата: 21.07.05 04:23
Оценка:
Здравствуйте, BorisKV, Вы писали:

BKV>Ладно тебе прикалываться — я на самом деле добрейшей души человек


Ты ещё и скромнейший

BKV>но это вообще дикий оффтоп.


Да, интим про осликов и японии — это здесь офтопик.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[22]: Checked exceptions... зло или добро?
От: dshe  
Дата: 21.07.05 08:26
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>dshe,


>> Что именно плохого в простроении логики программы на исключениях (прикладных)? Серьезно.


ПК>При широком использовании — неочевидность (неявность) связей и взаимодействия, с вытекающей сложностью в сопровождении.


Если логика посторена на unchecked исключениях, то действительно, связи становятся неявными. Но я если на checked?

Чтобы говорить более конкретно давайте рассмотрим пример.
Допустим, мы разрабатываем дизайн некого PersonFinder'а, который ищет людей по имени.

Вариант 1.
interface PersonFinder {
    /**
     * returns null if person has not been found
     */
    Person findPersonByName(String name);
}

В этом варианте PersonFinder возвращает null если человек не был найден. При этом вызывающий код обязан проверить полученный результат на null. Причем, он обязан исходя из неявного соглашения описанного в комментариях, которые не все и не всегда читают и пишут. Компилятор не выдаст ни error'а, ни warning'а если результат не будет проверен на null. Это основной недостаток данного подхода.

Вариант 2.
interface PersonFinder {
    /**
     * throws unchecked PatientNotFoundException if person has not been found,
     * never returns null
     */
    Person findPersonByName(String name);
}

В этом варианте вызывающий код не обязан проверять результат на null. Однако, если человек не был найден, возникнет исключение, которое, скорее всего, обработается на самом внешнем уровне обработки ошибок, самым общим образом (т.е. как и все остальные ошибки). Оно, конечно, будет более информативным, чем NullPointerException (в первом варианте), но все равно, вызывающий код мог бы обработать данную ситуацию по особому, например, выдать user friendly диалог и предложить новые критерии поиска (которые он мог бы взять из объекта-исключения). Для этого, данное исключение должно быть словлено где-то в непосредственной близости от самого вызова. И опять же, компилятор ничего не скажет если оно не будет обработано вообще.

Вариант 2a.
interface PersonFinder {
    /**
     * returns true if person has been found,
     */
    boolean isPersonExist(String name);
    /**
     * throws unchecked PatientNotFoundException if person has not been found,
     * never returns null
     */
    Person findPersonByName(String name);
}

Этот вариант является усовершенствованием варианта 2. При этом PatientNotFoundException считается ошибкой программирования, поскольку метод findPersonByName должен использоваться приблизительно таким образом:
if(patientFinder.isPersonExist(name)) {
    Person person = findPersonByName(name);
    // . . .
}

Это в принципе должно работать, но поскольку поиск человека стал двуэтапным, может возникнуть проблема если человек "исчез" после вызова isPersonExist, но до вызова findPersonByName.


Вариант 3.
interface PersonFinder {
    /**
     * throws checked PatientNotFoundException if person has not been found,
     * never returns null
     */
    Person findPersonByName(String name) throws PatientNotFoundException;
}


Этот вариант также является усовершенствованием второго, однако в другом направлении. PatientNotFoundException становится checked. Т.е. вызывающий код обязан его обработать (это гарантируется компилятором). Он может выдать user friendly диалог, а может просто перебросить его как unchecked, для того, чтобы оно обработалось как ошибка на самом внешнем уровне обработки ошибок.

Пока что, я предпочитаю последний вариант.
--
Дмитро
Re[22]: Checked exceptions... зло или добро?
От: dshe  
Дата: 21.07.05 08:26
Оценка:
Здравствуйте, IT, Вы писали:

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


D>>Что именно плохого в простроении логики программы на исключениях (прикладных)? Серьезно.


IT>Кроме того что упомянул Павел (неочевидность кода) можно добавить ещё то, что в больших количествах исключения существенно подтормаживают скорость выполнения приложения.


Согласен. Производительность может существенно повлиять на дизайн. Тем не менее не только исключения влияют на производительность в худшую сторону, но и такие вещи как reflection или даже виртуальный вызов. Но это не повод их избегать. Могу еще добавить, что исключения должны возникать в исключительных ситуациях. Но на мой взгляд, не всегда исключительная ситуация это именно ошибка.

IT>Но это всё меркнет по сравнению с одной фичей, которая по моему мнению находится в одном ряду с такими вещами как IntelliSense. Я имею ввиду Debug -> Exceptions -> Break into the debugger. Я это дело включаю всегда и на поиск 99% багов у меня уходит ровно 0 минут 0 секунд. Просто запускаешь приложение, выполняешь сценарий и в случае нештатной ситуации отладчик останавливается там, где произошло исключение. Помнится в 6-й студии была такая штука как break point с условием, работало, но изрядно подтормаживало. Даже был такой вопрос в MCSD треке типа как остановиться на 19874-й итерации цикла чтобы посмотреть что там происходит. Ничего этого теперь не нужно. Просто запускай приложение и жди.


Я тоже так иногда делаю когда пользуюсь debugger'ом. Правда, breakpoint обычно ставлю только на unchecked исключения. Но чаще просто смотрю в логи -- stacktrace'ов бывает достаточно, чтобы понять где и какая ошибка произошла.

IT>Так же замечено, что логикой на исключениях часто замазываются дыры толи по незнанию, толи по халатности. Начиная разбираться в конкретной ситуации чаще всего оказывается, что проблема решается более простыми и честными методами, а то и вообще try/catch просто используется для обхода бага, который надо исправить, а не замазывать.
--
Дмитро
Re[23]: Checked exceptions... зло или добро?
От: Курилка Россия http://kirya.narod.ru/
Дата: 21.07.05 08:31
Оценка:
Здравствуйте, dshe, Вы писали:

....

D>Вариант 2a.

D>
D>interface PersonFinder {
D>    /**
D>     * returns true if person has been found,
D>     */
D>    boolean isPersonExist(String name);
D>    /**
D>     * throws unchecked PatientNotFoundException if person has not been found,
D>     * never returns null
D>     */
D>    Person findPersonByName(String name);
D>}
D>


Несколько оффтоп, но поражает насколько наши программисты английского не знают...
Может несколько резко, но меня лично вот от таких названий "коробит".
Re[22]: Checked exceptions... зло или добро?
От: Cyberax Марс  
Дата: 21.07.05 08:32
Оценка:
IT wrote:

> Но есть одно но, которое часто омрачает такую сказочную жизнь. Это

> любители логики на исключениях. Если приложение кидает исключения
> налево и направо, то эту фичу приходится отключать и ловить ошибку что
> называется вручную, применяя старые дедовские методы. А на это уже
> уходит больше чем 0 секунд и даже на много больше чем 0 минут. Я
> человек ленивый и всё это меня ужасно раздражает и выводит из себя

Интересно, считать ли исключение об ошибке открытия файла — "прикладной"
ошибкой?

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[18]: Checked exceptions... зло или добро?
От: Cyberax Марс  
Дата: 21.07.05 08:34
Оценка:
VladD2 wrote:

> C>А как насчет прибить поврежденные данные и пересинхронизировать их с

> C>других узлов?
> Здорово. Именно этим занимаются те тысячи исключений в Ant-е (или где
> еще там?)?

Сейчас лень качать сырцы Ант'а — потом посмотрю и скажу.

> C>Нужно следить не столько за типами исключений, сколько за возможностью

> C>вылета "прикладных" исключений. То есть не логических ошибок в коде, а
> C>исключительных ситуаций в процессе работы.
> Вот за "прикладные исключения" нужно морду бить. Причем сильно и жестоко.

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

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[24]: Checked exceptions... зло или добро?
От: dshe  
Дата: 21.07.05 08:50
Оценка: +1
Здравствуйте, Курилка, Вы писали:

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


К>....


D>>Вариант 2a.

D>>
D>>interface PersonFinder {
D>>    /**
D>>     * returns true if person has been found,
D>>     */
D>>    boolean isPersonExist(String name);
D>>    /**
D>>     * throws unchecked PatientNotFoundException if person has not been found,
D>>     * never returns null
D>>     */
D>>    Person findPersonByName(String name);
D>>}
D>>


К>Несколько оффтоп, но поражает насколько наши программисты английского не знают...

К>Может несколько резко, но меня лично вот от таких названий "коробит".

Лично я давно привык к тому, что язык, который используется для идентификаторов лишь отдаленно напоминает английский. Должно быть, с точки зрения литературного английского языка лучше было бы назвать метод как-нибудь так: doesPersonExist или personExists или... кстати, предложите свой вариант. Но is в данном случае показывает, что метод возвращает boolean в соответствии с соглашением об именовании методов (несмотря на то, что с точки зрения литературного английского это, может быть, выглядит дико).
--
Дмитро
Re[24]: Checked exceptions... зло или добро?
От: dshe  
Дата: 21.07.05 09:07
Оценка:
Здравствуйте, Курилка, Вы писали:

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


D>>
D>>    boolean isPersonExist(String name);
D>>


К>Несколько оффтоп, но поражает насколько наши программисты английского не знают...

К>Может несколько резко, но меня лично вот от таких названий "коробит".

ок. как насчет варианта isPersonFound?
--
Дмитро
Re[25]: Checked exceptions... зло или добро?
От: Курилка Россия http://kirya.narod.ru/
Дата: 21.07.05 09:18
Оценка: -1
Здравствуйте, dshe, Вы писали:

D>Здравствуйте, Курилка, Вы писали:


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


D>>>
D>>>    boolean isPersonExist(String name);
D>>>


К>>Несколько оффтоп, но поражает насколько наши программисты английского не знают...

К>>Может несколько резко, но меня лично вот от таких названий "коробит".

D>ок. как насчет варианта isPersonFound?


Логичнее, на мой взгляд, was, просто если выделять с помощью is метод чисто как предикат, то почему же не использовать b как в венгерской нотации или постфикс P как в лиспе? На мой взгляд код должен в первую очередь читаться...
Просто вот пример коллеги — IsChildren, был естественно заменён на HasChildren, согласись в первоначальном варианте надо задуматься чтобы осознать смысл в коде...
В принципе я ничего не имею того, чтобы у вас были свои стандарты, но всёже несоответствие "обычным" (языковым) конструкциям вносит лишнюю сумятицу...
Хотя, может быть, для людей далёких от английского скорее наоборот, только вот чтож эти люди в программировании делают, где без английского ой как туго...
Re[23]: Checked exceptions... зло или добро?
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 21.07.05 14:16
Оценка: 1 (1)
D>Вариант 3.
D>
D>interface PersonFinder {
D>    /**
D>     * throws checked PatientNotFoundException if person has not been found,
D>     * never returns null
D>     */
D>    Person findPersonByName(String name) throws PatientNotFoundException;
D>}
D>


Есть еще одна более удобная разновидность этого варианта:

findPersonByName: aString
findPersonByName: aString ifAbsent: [ ... чегой-то делаем... ]


Правда в Java слишком велик синтаксический оверхед, а вот C#2 такое уже можно использовать
... << RSDN@Home 1.1.4 stable rev. 510>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[23]: Checked exceptions... зло или добро?
От: Павел Кузнецов  
Дата: 21.07.05 14:24
Оценка: 16 (3)
dshe,

d> Если логика посторена на unchecked исключениях, то действительно, связи

d> становятся неявными. Но я если на checked?

Тогда в дело вступают остальные факторы, описанные IT.

d> Чтобы говорить более конкретно давайте рассмотрим пример.

d> Допустим, мы разрабатываем дизайн некого PersonFinder'а, который ищет
d> людей по имени. <...>

d> Вариант 3.

d>
 d> interface PersonFinder {
 d>  /**
 d>   * throws checked PatientNotFoundException if person has not been
 d> found,  * never returns null
 d>   */
 d>  Person findPersonByName(String name) throws PatientNotFoundException;
 d> }
 d>


d> <...>

d> Пока что, я предпочитаю последний вариант.

В C++ я предпочитаю такой вариант:
boost::optional< Person >
findPersonByName( std::string name );

или, для C#:
Person?
findPersonByName( string name );

или (вот здесь я уже не вполне уверен, можно ли на Java так сделать --
если нет, тем хуже для Java ):
Optional<Person>
findPersonByName( String name );

И не нужно никаких лишних комментариев и, тем более, исключений.

Кроме того, вариант с типами работает не только при возвращении значений из
функций, но и внутри функций:
boost::optional<Person> person;
if ( ... )
  person = ...;
else if ( ... )
  person = ...;
else
  ...

...

// теперь физически нельзя пропустить тот момент, что person может не иметь
// значения в данной точке

if ( person )
  do_something( *person );

...


И, что, не менее важно, при передаче аргументов (лень придумывать "реальное"
название, но, полагаю, понятно, что случаев, хоть отбавляй):
void f( T1 t1, T2 t2, boost::optional<Person> );


Случай с использованием исключений внутри функции реализуем, но приводит к
изменению структуры кода, а в случае с несколькими объектами -- к его усложнению
и запутыванию.

Случай с передачей аргументов исключениями не выражается, что демонстрирует
плохую масштабируемость подобноо подхода.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[24]: Checked exceptions... зло или добро?
От: dshe  
Дата: 21.07.05 14:29
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

D>>Вариант 3.

D>>
D>>interface PersonFinder {
D>>    /**
D>>     * throws checked PatientNotFoundException if person has not been found,
D>>     * never returns null
D>>     */
D>>    Person findPersonByName(String name) throws PatientNotFoundException;
D>>}
D>>


ANS>Есть еще одна более удобная разновидность этого варианта:


ANS>
ANS>findPersonByName: aString
ANS>findPersonByName: aString ifAbsent: [ ... чегой-то делаем... ]
ANS>


ANS>Правда в Java слишком велик синтаксический оверхед, а вот C#2 такое уже можно использовать


+1 за оригинальность.

В Java я бы это сделал так:
public interface PersonFinder {
    public interface FindHandler {
        public void personFound(PersonFinder finder, Person person);
        public void personNotFound(PersonFinder finder, String name);
    }
    public void findPersonByName(String name, FindHandler handler);
}

и использование:
finder.findPersonByName(name, new PersonFinder() {
    public void personFound(PersonFinder finder, Person person) {
        // . . .
    }
    public void personNotFound(PersonFinder finder, String name) {
        // . . .
    }
})

Но не думаю, что это было бы очень удобно.
--
Дмитро
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.