VladD2 wrote:

> C>Уже сделано два года назад в JBoss — там как раз есть декларативные
> C>транзакции на графах объектов.
> Это специализированное решение для узкого круга задач. Попробуй там
> вэлью-типы откатить или даже объекты не унаследованные от какй-нить хрени.

Ничего не нужно наследовать — JBoss инструментирует байт-код, так что
все работает прозрачно (если, конечно, явно не пытаться испортить себе
жизнь).

Причем поддерживается _прозрачное_ распространение транзакций на базы
данных или другие ресурсы (для которых есть коннекторы), так что
становится очень удобно писать бизнес-логику.

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

На самом деле, эта задача имеет еще одно, гораздо более простое и элегантное (на мой взгляд) решение:

void
try_to_be_exception_safe()
    {
        std::string s( "We are going to greet everyone" );
        try
            {
                std::string tmp( "We are going to greet" );

                throwable_action( tmp );

                // Здесь гарантированно нет исключений.
                s.swap( tmp );
            }
        catch( const std::exception & x )
            {
                std::cerr << "Oops! Exception: " << x.what() << std::endl;
            }

        std::cout << "And now: " << s << std::endl;
    }

А вы говорите -- новая платформа, новый язык...
Оказывается, все проще. Гораздо проще.

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

C>AndrewVK wrote:

>> ПК>-1. При недостаче памяти в C++ вылетает std::bad_alloc.
>> Даже если памяти не хватило внутри апишной функции?

C>При недостатке памяти АПИшные функции будут возвращать код ошибки.

Который лучше сразу конвертить в std::bad_alloc для для однообразности работы и в соответствии с соглашениями стандартной библиотеки C++.

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

ПК>>или (вот здесь я уже не вполне уверен, можно ли на Java так сделать --
ПК>>если нет, тем хуже для Java ):
ПК>>

ПК>>Optional<Person>
ПК>>findPersonByName( String name );
ПК>>

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

VD>Кстати, в C# с большой вероятностью, а в Яве так на 100% Person будет ссылочным типом, так что даже Person? и т.п. не потребуется. Можно просто возвращать null если человека нет.
Возвращать просто null вместо оссылки на какой-либо объект в Java — это плохая практика.
Во-первых, с большей долей вероятности в рантайме произойдёт unchecked-исключение java.lang.NullPointerException, которое будет брошено в вызывающем методе или немного выше (если вызывающий метод является "трансфером объекта").
Во-вторых, для обработки возвращаемого значения (null/not null) придётся писать дополнительный код в вызывающем методе, проверяющий, равна ли ссылка null.
В-третьих, понадобиться обязательно заглянуть в документацию по спецификации вызываемого метода и возвращаемого значения. (Вот удивиться прикладной программист, когда узнает, что метод иногда возвращает "ничего". Не правда ли, занакомое состояние, когда программируешь на C#? )
В случае с объявленным checked-исключением или с применением паттерна NullObject в вызываемом коде таких проблем не возникает: вызывающий код пишется гладко — если возникает checked-исключение, то оно замечается на этапе компиляции и, естественно обрабатывается/пересылается; если используется NullObject — это ещё лучше, работа с исключительной ситуацией не требуется.

p.s. Навеяно книжками:
1. Джошуа Блох "Эффективное программирование", статья 27 "Возвращайте массив нулевой длины, а не null" (то же самое и по строками);
2. Стивен Стелтинг "Java без сбоев: обработка исключений, тестирование, отладка". — кстати один из авторов книжки "Применение шаблонов Java".

Дополню себя же.

По словам Мартина Фаулера (из книги "Рефакторинг: улучшение существующего кода") паттерн NullObject впервые заметил Рон Джеффриз. Вот небольшая выдержка из статьи:

Мы впервые стали применять паттерн нулевого объекта (NullObject), когда Рич Гарзанити обнаружил, что код системы часто проверяет, существует ли объект, прежде чем послать ему сообщение (здесь: "сообщение" — метафора вызова метода в ООП). Мы запрашивали у объекта его метод person, а затем сравнивали результат с null. Если объект присутствовал, мы запрашивали у него метод rate. Это делалось в нескольких местах, и повторение кода в них стало нас раздражать.
Поэтому мы создали объект отсутсвующего лица, который сообщал, что у него нулевой (не null!! — Прим. моё) rate (мы называем наши null-объекты существующими объектами). Вскоре у отсутствующего лица было уже много методов. Сейчас у нас уже больше 80 классов нулевых объектов.
Чаще всего нулевые объекты мы применяем при выводе информации. Например, когда выводится информация о лице, то у соответствующего объекта может отсутствовать любой из примерно 20 атрибутов. Если бы они могли принимать значение null, вывод информации о лице стал бы очень сложным. Вместо этого мы подключаем различные нулевые объекты, которые умеют отображать себя правильным образом. В результате мы избавились от большого объёма процедурного кода.
<...дальше идёт рассказ о применении NullObject's для тестовых транзакций в БД и коллекции бухгалтерских данных...>
<...>
Интересная особенность применения нулевых объектов состоит в том, что почти никогда не возникают аварийные ситуации. Поскольку нулевой объект отвечает на те же сообщения, что и реальный объект, система в целом ведёт себя обычным образом. Из-за этого иногда трудно локализовать проблему, потому что всё работает нормально.
<...>
Помните, нулевые объекты постоянны — в них никогда ничего не меняется. Соответственно, мы реализуем их по паттерну "Одиночка" (Singleton pattern). Например, при каждом запросе отсутствующего лица вы будете получать один и тот же экземпляр этого NullObject-класса.

У Мартина Фаулера в книжке как раз и объяснено на примерах где, когда и как желательно применять паттерн NullObject.

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

S>Офф: У меня был великолепнейший случай бага с преобразованиями часовых поясов — пояс вычитался, вместо того, чтобы прибавляться. К сожалению, у нас GMT +6, и время получалось правильное. Только когда код стали тестировать при GMT +11 все и обнаружилось.

Офф: а какой у меня был интереснейший баг, который проявляется только 31 декабря високосного года... Вот как раз в прошлом году и пришлось по-стахановски поработать, чтоб выдать клиентам заплатку, которая только на этот день и нужна.

C>С chaining'ом все просто — одно исключение "вкладывается" в другое, то
C>есть получается цепочка исключений. Типа SQLException был вызван
C>NullPointerException'ом, который был вызван OutOfBoundsException'ом. С
C>jdk1.4 это стандартная фича.

Это типа

catch(SqlException ex)
{
throw new MyException("message", ex);
}

Так это уже есть в шарпе. Можно по InnerException разбирать кому стало плохо.

E>выдал бы предупреждение о том, что в g() вызов функции f() может привести к возникновению исключения.

Любят сишники предупреждения

А в чем польза этого конкретно предупреждения, все равно многие возможные исключения на уровне компиляции не отловишь.

VD>>Ну, или кривость дизайна проекта.
M>Я бы по остерегся бы так лихо отзываться об апачевских проектах.

Я думаю, что Влад имел в виду "вынужденность" данного дизайна. И этот дизайн уступает в этом смысле аналогичному не на Java (а на C# )

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

E>>Вот собственно об этом я и говорил. Спецификация исключений, имхо, в теории полезная штука. Но вот в C++ и Java она реализована, имхо, неудачно.

VD>Согласен с одной оговоркой. Описание исключений генерируемых методом должен делать компилятор. Причем без единой подскзки. Вся информация у него есть. А я как потребитель должен иметь возможность легко узнать список исключений которые может выдать тот или иной метод.

в случае, когда код — удаленный, компилятору доступна только спецификация (контракт, интерфейс). я к тому, что спецификация метода — первична, ибо картину для случаев, когда ее первичностью можно пренебречь, перечеркивает хотя бы один "неудобный" пример.

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

C0s>в случае, когда код — удаленный, компилятору доступна только спецификация (контракт, интерфейс). я к тому, что спецификация метода — первична, ибо картину для случаев, когда ее первичностью можно пренебречь, перечеркивает хотя бы один "неудобный" пример.

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

Тут нужно сравнивать бенефит от наличия исчерпывающего списка и проблемы возникающие в следствии этого. Есть мнение, что проблем куда больше.

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

VD>Checked exceptions. Правда это никак не мешает сайту работать годами без перезагрзки и даже модифицироваться на ходу.

можно примерно сказать как? для чайника

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

VD>>Checked exceptions. Правда это никак не мешает сайту работать годами без перезагрзки и даже модифицироваться на ходу.

I>можно примерно сказать как? для чайника

Можно. Отчего же нельзя? Руками напимсал. На C#. Вот в ближайшее время хочет переписать теми же рукаи на Nemerle.

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

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

I>>можно примерно сказать как? для чайника

VD>Можно. Отчего же нельзя? Руками напимсал. На C#. Вот в ближайшее время хочет переписать теми же рукаи на Nemerle.

Влад, ты точно программист. Ответ абсолютно верен но абсолютно не несет смысловой нагрузки

А можно в общих словах технологию?

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

I>Влад, ты точно программист. Ответ абсолютно верен но абсолютно не несет смысловой нагрузки

Какой вопрос таков и ответ. Вообще я рассчитывал на наличие чувства юмора у собеседника.

I>А можно в общих словах технологию?

Собственно расказывать особо не очем. Сначала был W2K, ASP, Jet, VS2003. Потом W2003, .Net 1.х, MS SQL 2000, VS2003. Потому W2003, .Net 2.0, MS SQL 2005, VS2005. Плюсь IT-шный Тулкит потихоничку использоваться начал.