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

_>Как раз scope_exit гораздо удобнее finally — Евгений уже показал это в сообщение выше.

Да, для ненужных кейсов удобнее, линейная композиция и все такое.

>>>А вот возможность понять чем вызван запуск деструктора (раскруткой стека исключением или же штатным выходом) даёт совершенно другие возможности, как раз являющиеся заменой уже catch.
I>>Нету такой возможности.

_>А данная возможность как раз продемонстрирована по ссылке в первом сообщение темы. )))

Если ты в деструкторе вызываешь какую то логику, то надо ждать и исключения. Опаньки !

_>Что-то ты понаписал кучу всего, включая какую-то свою личную классификацию ситуаций. А пользы от этого ноль.

Это просто примеры. Что характерно, ты их ниасилил, подозреваю, просто не читал

>На самом деле на практике существует ровно две известных практики применения исключений:

Вообще то кроме 'практик' есть следующее
1 обработка ошибок
2 распространение ошибок — ты уже в который раз эту часть игнорируешь и не даёшь ответа, как же эту часть реализовать

_>2. Применение исключений и для обработки критических ошибок и для обработки банальных неудачных вызовов. С таким применением согласны уже далеко не все. И вот лично мне он тоже не особо нравится. Потому что на мой вкус код вида (схематичный пример):

_>

_>void OnSaveButton()
_>{
_>    if(!SaveDocument()) MessageBox("Не могу сохранить документ");
_>}
_>

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

И вот где то глубоко-глубоко произошло исключение. Опаньки ! Как доставить на самый верх ?
Вобщем пример в студию !


_>Так вот моя мысль в данной теме была в том, что если применить для второго варианта исключения в формате описанном в той статье, т.е. что-то вроде
_>

_>void OnSaveButton()
_>{
_>    SCOPE_FAIL{ MessageBox("Не могу сохранить документ"); };
_>    SaveDocument();
_>}
_>

_>то это будет уже не такой уж и плохой вариант для большинства случаев

1 что будет, если код, там где вызов MessageBox бросит исключение ?
2 как переписать на скопы такой пример:

Expression resultFromString(String str) {
   try {
       Expression expression = new Expression(str);
           // считаем долго и рекурсивно  
       return expression.calculate();
   } catch(CalculationFailure ex) {
       return Expression.NotANumber;
   }
}

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

_>Как раз scope_exit гораздо удобнее finally — Евгений уже показал это в сообщение выше.

Да, для ненужных кейсов удобнее, линейная композиция и все такое.

>>>А вот возможность понять чем вызван запуск деструктора (раскруткой стека исключением или же штатным выходом) даёт совершенно другие возможности, как раз являющиеся заменой уже catch.
I>>Нету такой возможности.

_>А данная возможность как раз продемонстрирована по ссылке в первом сообщение темы. )))

Если ты в деструкторе вызываешь какую то логику, то надо ждать и исключения. Опаньки !

_>Что-то ты понаписал кучу всего, включая какую-то свою личную классификацию ситуаций. А пользы от этого ноль.

Это просто примеры. Что характерно, ты их ниасилил, подозреваю, просто не читал

>На самом деле на практике существует ровно две известных практики применения исключений:

Вообще то кроме 'практик' есть следующее
1 обработка ошибок
2 распространение ошибок — ты уже в который раз эту часть игнорируешь и не даёшь ответа, как же эту часть реализовать

_>2. Применение исключений и для обработки критических ошибок и для обработки банальных неудачных вызовов. С таким применением согласны уже далеко не все. И вот лично мне он тоже не особо нравится. Потому что на мой вкус код вида (схематичный пример):

_>

_>void OnSaveButton()
_>{
_>    if(!SaveDocument()) MessageBox("Не могу сохранить документ");
_>}
_>

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

И вот где то глубоко-глубоко произошло исключение. Опаньки ! Как доставить на самый верх ?
Вобщем пример в студию !


_>Так вот моя мысль в данной теме была в том, что если применить для второго варианта исключения в формате описанном в той статье, т.е. что-то вроде
_>

_>void OnSaveButton()
_>{
_>    SCOPE_FAIL{ MessageBox("Не могу сохранить документ"); };
_>    SaveDocument();
_>}
_>

_>то это будет уже не такой уж и плохой вариант для большинства случаев

1 что будет, если код, там где вызов MessageBox бросит исключение ?
2 как переписать на скопы такой пример:

Expression resultFromString(String str) {
   try {
       Expression expression = new Expression(str);
           // считаем долго и рекурсивно  
       return Expression.Transform(expression.calculate(), Expression.Type('Miles'));
   } catch(CalculationFailure ex) {
       return Expression.NotANumber;
   }
}