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

Generator generator = new Generator()
....
try
{
    Result result =  generator.gentrate(data, outStream);
    if(result.hasWarnings())
    {
        .....
    }
}

Или так

Generator generator = new Generator()
....
try
{
    generator.gentrate(data, outStream,context);
    if(context.hasWarnings())
    {
        .....
    }
}

Может быть exception ?

Спасибо за внимание.

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

A>Может быть exception ?

Почему бы и нет? Всё таки коды возврата — это прошлый век.

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

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

A>>Может быть exception ?

IT>Почему бы и нет? Всё таки коды возврата — это прошлый век.
IMHO для такой задачи эксепшн кидать не кузяво.
Лучше отдавай назад коллекцию предупреждений/ошибок возникших при отработке.

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

IT>>Почему бы и нет? Всё таки коды возврата — это прошлый век.
M>IMHO для такой задачи эксепшн кидать не кузяво.
M>Лучше отдавай назад коллекцию предупреждений/ошибок возникших при отработке.

Вообще-то эксепшин — это объектно-ориентированный код возврата, что тут некузявого. Видел приложения использующие COM без всяких обёрток? Обработка кодов возврата там занимает большую часть кода. Данный пример очень простой, но даже на нём мы имеем 5 строчек кода вместо одной. А стоит ему только чуть-чуть усложниться как усложнится и логика обработки кодов возврата. Вместо двух строчек бизнес логики мы будем иметь 10 строк непонятно чего. В общем, коды возврата sux в любых своих проявлениях.

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

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

IT>>>Почему бы и нет? Всё таки коды возврата — это прошлый век.
M>>IMHO для такой задачи эксепшн кидать не кузяво.
M>>Лучше отдавай назад коллекцию предупреждений/ошибок возникших при отработке.

IT>Вообще-то эксепшин — это объектно-ориентированный код возврата, что тут некузявого. Видел приложения использующие COM без всяких обёрток?
Видел, и?
IT>Обработка кодов возврата там занимает большую часть кода.
И это не вызыфвает возражений
IT>Данный пример очень простой, но даже на нём мы имеем 5 строчек кода вместо одной. А стоит ему только чуть-чуть усложниться как усложнится и логика обработки кодов возврата. Вместо двух строчек бизнес логики мы будем иметь 10 строк непонятно чего. В общем, коды возврата sux в любых своих проявлениях.

Во первых никаких кодов я не заметил — есть нормальный объект — результат операции. Насколько я понял результат может состоять из множества предупреждений и ошибок. И вот именно в такой постановке задачи исключения совершенно не подходят.

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

IT>>Вообще-то эксепшин — это объектно-ориентированный код возврата, что тут некузявого. Видел приложения использующие COM без всяких обёрток?
M>Видел, и?

Жуть!

IT>>Обработка кодов возврата там занимает большую часть кода.
M>И это не вызыфвает возражений

Странно. У меня вызывает не только возражение, но и отвращение

M>Во первых никаких кодов я не заметил — есть нормальный объект — результат операции.

Какая разница объект это или не объект. Пусть это будет объект возврата. Ключевое слово здесь 'возврата'. Я должен обработать этот код сразу после его получения и в том же месте где я его получил. В случае вложенных вызовов я должен протолкнуть его наверх и так по всем уровням.

M>Насколько я понял результат может состоять из множества предупреждений и ошибок. И вот именно в такой постановке задачи исключения совершенно не подходят.

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

IT wrote:
> Здравствуйте, migel, Вы писали:
> M>Во первых никаких кодов я не заметил — есть нормальный объект — результат операции.
> Какая разница объект это или не объект. Пусть это будет объект возврата. Ключевое слово здесь 'возврата'. Я должен обработать этот код сразу после его получения и в том же месте где я его получил. В случае вложенных вызовов я должен протолкнуть его наверх и так по всем уровням.

Я пожалуй соглашусь с migel'ем: исключение — это ОШИБОЧНАЯ ситуация, при
которой нет возможности продолжить работу. Это не ожидаемая ситуация,
которую нужно просто определенным образом разрулить, как это происходит
в этом случае. Ведь по сути, нужно просто выяснить, были ли какие-нибудь
проблемы с генерацией документа. Вот если его не удалось сгенерировать
(например, картинка в некорректном формате) — вот тут скорее всего
исключение. А если удалось, но не красиво, то нет исключения: успех да и
только.
Так что в описанной ситуации я бы использовал 1-й вариант: он более
понятный чем 2-й (если конечно не введено уже понятие контекста,
используемое для этих целей).

achmed пишет:

Всем спасибо за советы/
Cогласен по поводу exception, exception — это ошибка.
Вспомним COM, все методы всех интерфейсов возвращают HRESULT, для
чтобы облегчить жизнь, используются врапперы (директива #import, comet),
примерно так

HRESULT hr = pStream->Read(.....)
if(FAILED(hr))
    throw com_excpetion(hr,pStream);
// и никаких exception для SUCCEEDED(hr)

exception — это замены коду ошибки (но не коду возврата) в
обьектно-ориентированном
стиле в общем стиле, так пишут в умных книгах .

Придумал, хотя нет, вспомнил еще один вариант, подходящий к данной
ситуации — callback нитерфейс.

[code]

Generator generator = new Generator()
WaringsListenerImpl listener = new WaringsListenerImpl();
generator.setWaringsListener(listener)ж
....
try
{
generator.gentrate(data, outStream);
if(listener.hasWarnings())
{
.....
}
}

[code]

achmed wrote:
> Придумал, хотя нет, вспомнил еще один вариант, подходящий к данной
> ситуации — callback нитерфейс.
> [code]
> Generator generator = new Generator()
> WaringsListenerImpl listener = new WaringsListenerImpl();
> generator.setWaringsListener(listener)ж
> ....
> try
> {
> generator.gentrate(data, outStream);
> if(listener.hasWarnings())
> {
> .....
> }
> }
> [code]
мое скромное ИМХО: этот код не очевиден для читающего. И это при том,
что слушалка (а по сути притянутая за уши реализация Visitor) по сути
тут не нужна, разве что тебе нужно своим кодом отслеживать события в
объекте, хрен знает как болтающемся в приложении. А тут все просто: один
вызов. Хоть туда слушалку передавай, как с контекстом. Вот если у тебя
стоит задача, что, например, слушалка слушает и управляет процессом
генерации (например, по накоплении 5 предупреждений просто сообщает о
необходимости прервать генерацию, вот это другое дело. В твоем случае,
ИМХО опять же, стоит вернуть коллекцию ворнингов и не париться.

Здравствуйте, Козьма Прутков, Вы писали:

КП>Я пожалуй соглашусь с migel'ем: исключение — это ОШИБОЧНАЯ ситуация, при которой нет возможности продолжить работу.

А разве это не так? Что тогда подразумевается под "документ не всегда может быть "хорошо сгенерирован" (например, слишком большая картинка,"? Я это понял как не может быть сгенерирован.

IT wrote:
> Здравствуйте, Козьма Прутков, Вы писали:
>
> КП>Я пожалуй соглашусь с migel'ем: исключение — это ОШИБОЧНАЯ ситуация, при которой нет возможности продолжить работу.
>
> А разве это не так? Что тогда подразумевается под "документ не всегда может быть "хорошо сгенерирован" (например, слишком большая картинка,"? Я это понял как не может быть сгенерирован.

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

Здравствуйте, Козьма Прутков, Вы писали:

КП>а я понял, что он сгенерирован, но "не хорошо" Типа, жить можно, но картинка вылазит за пределы страницы... Ручками придется поправить или еще что-то.

Типа чуть-чуть беременный... Понял

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

IT>А разве это не так? Что тогда подразумевается под "документ не всегда может быть "хорошо сгенерирован" (например, слишком большая картинка,"? Я это понял как не может быть сгенерирован.
Одно из моих личных IMHO.
Производители компиляторов (по крайней мере С++ и JIT) так старались чтобы исключительные ситуации были исключительными по самые уши. То бишь обработки их более чем тормозные. Поэтому, если можно обработать (а практически всегда можно) ошибки логикой и не доводить до исключения, то их нужно обрабатывать логикой. Исключения нужны только для отладки.

С уважением, Gleb.

GlebZ wrote:
> Здравствуйте, IT, Вы писали:
>
> IT>А разве это не так? Что тогда подразумевается под "документ не всегда может быть "хорошо сгенерирован" (например, слишком большая картинка,"? Я это понял как не может быть сгенерирован.
> Одно из моих личных IMHO.
> Производители компиляторов (по крайней мере С++ и JIT) так старались чтобы исключительные ситуации были исключительными по самые уши. То бишь обработки их более чем тормозные. Поэтому, если можно обработать (а практически всегда можно) ошибки логикой и не доводить до исключения, то их нужно обрабатывать логикой. Исключения нужны только для отладки.
>
> С уважением, Gleb.
вот с этим позволю себе не согласиться. Да, исключение штука
тяжеловесная на С++ (раскрутка стека в основном), но по выходу из
функции как ни крути эти действия совершаются. Это раз. В .NET нет
раскрутки стека как таковой (если конечно нет finally с вызовом Dispose
и т.п.). Так что исключение там — довольно легковесный механизм.
Вопрос стоит, по большому счету, в идее и в том, в какую сторону этот
код потом будет расти, чтобы выбранный механизм не стоял на пути
расширяемости, внесения ожидаемых изменений и т.п.

Здравствуйте, Козьма Прутков, Вы писали:

КП>вот с этим позволю себе не согласиться. Да, исключение штука
КП>тяжеловесная на С++ (раскрутка стека в основном), но по выходу из
КП>функции как ни крути эти действия совершаются. Это раз. В .NET нет
КП>раскрутки стека как таковой (если конечно нет finally с вызовом Dispose
КП>и т.п.). Так что исключение там — довольно легковесный механизм.
В НЕТ генерация Exception очень тяжелая операция. Среда на выполнении просматривает стек куда надо переместиться, и заполняет объект Exception (который обязан быть по стандарту CLS) в том числе информацие о всем стеке.
КП>Вопрос стоит, по большому счету, в идее и в том, в какую сторону этот
КП>код потом будет расти, чтобы выбранный механизм не стоял на пути
КП>расширяемости, внесения ожидаемых изменений и т.п.
Расширять с помощью exception — накладное дело. Нет ничего более постоянного чем временно. Тут нужна явная обработка ошибок (или неожиданностей). Мне больше нравится второй вариант. В этом случае, по выбору каждый механизм сможет обработать те или иные особенности по своему выбору. Ну а кто-нибудь может сказать(пометить), что контекст не является достойным для вывода. Ну и обработать эту пометку на каком-то этапе.

С уважением, Gleb.

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

GZ>Производители компиляторов (по крайней мере С++ и JIT) так старались чтобы исключительные ситуации были исключительными по самые уши. То бишь обработки их более чем тормозные. Поэтому, если можно обработать (а практически всегда можно) ошибки логикой и не доводить до исключения, то их нужно обрабатывать логикой. Исключения нужны только для отладки.

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

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

Exception в этом случае не годится. Потому что exception, если его не поймать, нарушит штатный ход работы вызывающего кода. А поймать можно забыть. Да и вызывающий код может быть разный — в каких-то случаях эта информация нужна, в каких-то нет. Придется везде лоывить этот exception и .. тут же пропускать. Очень некрасиво.

Имхо: если это единичный случай — вернуть класс с информацией о результатах генерации. Если такие вещи нужны много где и по каким-то причинам не хочется засорять прототипы этими классами — придумывать механизм, который будет переносить подобную информацию от "серверного" кода в "клиентский" параллельно обычным возвращаемым значениям, через какие-то контексты и т.п.

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

iT>Exception в этом случае не годится. Потому что exception, если его не поймать, нарушит штатный ход работы вызывающего кода. А поймать можно забыть.

А если в стриме место закончилось и ты забыл поймать исключение, то это нормально?

iT>Да и вызывающий код может быть разный — в каких-то случаях эта информация нужна, в каких-то нет. Придется везде лоывить этот exception и .. тут же пропускать.

А это ещё зачем? Вся прелесть исключений в том, что если тебе не надо, то не лови, и в простейшем случае на визуальную форму тебе понадобится один блок try / catch. В ASP.NET даже и этого не надо, достаточно определить страницу для вывода ошибки.

iT>Очень некрасиво.

Забыть обработать код возврата ещё легче. Более того, это не просто некрасиво, это ещё и очень опасно. Это потенциальный источник таких проблем, которые могут не всплыть ни при разработк ни при тестировании. Ловить их очень трудно, а поймав, приходится долго разбираться в коде, чтобы понять как так внести изменения, чтобы ничего не сломать.

На самом деле, чтобы не уйти во флейм нам нужен ответ автора топика на вопрос — большая картинка для него это штатная ожидаемая ситуация или нет, может ли он после этого продолжить работу?

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

IT>При таком подходе код из бизнес логики очень легко превращается в логику обработки кодов возвратов и проталкивания их наверх, особенно при глубокой вложенности вызовов.
Почти точно. Только обычно, это управляется состоянием объектов задействованных в логике. И в зависимости от их состояния логика и управляется. А ошибка, всего лишь часть состояния.

IT>Есть очень простое правило. Исключения не должны использоваться в логике работы программы. Т.е. тогда, когда результат ошибки ожидаем программой и может быть ею исправлен, либо использован другой путь для дальнейших вычислений. Если же программа не может продолжить нормальное выполнение, то должно быть сгенерировано исключение. При таком подходе количество исключений в системе минимально. Например, елси приложение взаимодействует с пользователем. То исключение может произойти единовременно в момент воздействия пользователя на систему. Если это сервис или сервер приложений, то одно исключение на выполняемую операцию. Грубо говоря "смогла / не смогла". В этом случае тормозами исключений можно пренебречь.
Согласен. В некоторых случаях это необходимо(еще пример пересылка ошибки через remoting, SOAP, rollback). Но тут есть еще некоторый момент кроме тормознутости. Включение исключений в логику нарушает инкапсуляцию этой логики. Если класс(модуль) используется во многих местах, и его логика надеется что исключение будет обработано, то тут может быть и обломс. В этом виде мне нравится подход Java к документированию исключений в декларации метода.

Замечательная вещь была встречена в Oracle, когда он сообщал о том, что до протухания пароля осталось столько-то времени через ошибку при коннекте. В результате, нужно тебе это, или не нужно, это приходилось учитывать.

С уважением, Gleb.

IT пишет:

>
> На самом деле, чтобы не уйти во флейм нам нужен ответ автора топика на
> вопрос — большая картинка для него это штатная ожидаемая ситуация или
> нет, может ли он после этого продолжить работу?
>
Да, это ожидаемая ситуация, при которой генератор должен продолжить свою
работу, но
известить об этом контекст, в точности как варнинги компилятора, мне
казалось, что я
с самого начало это обьяснил, в следующий раз постраюсь выражаться яснее.