Зачем нужны исключения?

@Melvil · Регистрация: 20.05.2015

Студворк — интернет-сервис помощи студентам

Добрый вечер, прочитал статью об исключениях, не очень понимаю, почему бы не заменить их просто оператором if?

Вот код с исключением:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
#include <iostream>;
using namespace std;
 
int main()
{
    setlocale(LC_ALL, "rus");
 
    int num1;
    int num2;
    int var = 2;
 
    while(var--)
    {
        cout << "Введите значение num1: ";
        cin >> num1;
        cout << "Введите значение num2: ";
        cin >> num2;
 
        cout << "num1 + num2 = " << num1 + num2 << endl;
        cout << "num1 / num2 = ";
 
        try //код, который может привести к ошибке, располагается тут
        {  
            if (num2 == 0)
            {
                throw 123; //генерировать целое число 123
            }
            cout << num1 / num2 << endl;   
        }
        catch(int i)//сюда передастся число 123
        {
            cout << "Ошибка №" << i << " - на 0 делить нельзя!!!!" << endl;
        }
 
        cout << "num1 - num2 = " << num1 - num2 << endl;
        cout << "=================================" << endl << endl;
    }
 
    cout << "Программа завершила работу!" << endl << endl;;
 
return 0;
}

А можно просто:

C++
1
2
3
4
if(num=0)
{
// Действие
}

Без catch, try, throw. Можете объяснить разницу?

@AncientPenguin · 17.08.2015, 15:09

Сообщение от hoggy

ну и что? причем тут это?

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

@hoggy · 18.08.2015, 10:14

Сообщение от AncientPenguin

Вы мне пытаетесь доказать что

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

Сообщение от AncientPenguin

Внимание вопрос: вы уверены что две разные функции находящиеся в двух разных проектах, при этом одна из этих функций вообще о существовании второй не знает, это одно и то же место с точки зрения логики?

похоже, что вы не понимаете о чем идет речь.

знаете такое правило на плюсах:
"кто память выделял, тот и должен её освобождать" ?

теперь вот вам другое правило:
"кто запустил небезопасную процедуру, тот и должен разгребать последствия".

пример:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
void foo()
{
    try{
        bar();
    }
    catch(std::exception& e)
    {
        ... 
    }
}
 
int main()
{
    foo();
}

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

потому что наверху функция main понятия не имеет ни о каком bar,
и понятия не имеет, что там могло произойти,
и как это теперь можно исправить.

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

@Mr.X · 18.08.2015, 10:45

Сообщение от hoggy

кто запустил небезопасную процедуру, тот и должен разгребать последствия

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

@hoggy · 18.08.2015, 10:50

Сообщение от Mr.X

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

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

@AncientPenguin · 18.08.2015, 21:37

Сообщение от hoggy

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

Сударь я с вами в семантике соревноваться не хочу, доказывали, утверждали, декларировали какая разница в данном случае.

Сообщение от hoggy

похоже, что вы не понимаете о чем идет речь.

Это вы не понимаете о чем речь. Я написал что можно обрабатывать ошибки в другом месте, ибо все что не прямо в том же месте пространства-время-оперативной памяти т.е. прямо там где вылезла ошибка (+- строчка) это не то же самое место.

Сообщение от hoggy

знаете такое правило на плюсах:
"кто память выделял, тот и должен её освобождать" ?

Я точно знаю что плюсы можно "привести" к С# и забыть про ключевое слово delete.

Сообщение от hoggy

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

Один уровень выше по стеку не может логически быть тем же самым местом, ну не притворяйтесь торшером. Когда я писал обрабатывать в другом месте я и имел ввиду на 1-2 функцию выше.

@hoggy · 19.08.2015, 08:27

Сообщение от AncientPenguin

доказывали, утверждали, декларировали какая разница в данном случае.

разница в мотивах действий.

Сообщение от AncientPenguin

Я написал что можно обрабатывать ошибки в другом месте

то есть, "тем местом" вы полагаете тупо ту строчку кода, где фигурирует throw std::runtime_error ?

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

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

поэтому, в этом смысле ваш тезис не имеет смысла.

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

Сообщение от AncientPenguin

Один уровень выше по стеку не может логически быть тем же самым местом

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

простой пример:

C++
1
2
3
4
5
6
7
8
9
10
11
12
try{
 
    myvec.at(100500); //<--- причина аварийной ситуации заключена в этой строке
     // а не внутри метода at
}
catch(std::out_range& e)  
{
    ...   //<---- именно здесь лучше всего разгребать последствия
    // потому что здесь мы знаем: что запускали, зачем запускали
    // насколько это важно для работы
    // и как может отразиться на работе провал операции
}

@AncientPenguin · 19.08.2015, 10:36

Сообщение от hoggy

разница в мотивах действий.

Какая?

Сообщение от hoggy

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

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

Сообщение от hoggy

простой пример:

А где доказательства что функция myvec.at(100500); не вызвала еще функцию, которая вызвала еще функцию, в которой выбросилось исключение. И да, функция в сторонней библиотеке.

@hoggy · 19.08.2015, 12:25

Сообщение от AncientPenguin

Какая?

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

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

и тд и тп.

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

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

к сожалению от вас я пока ещё ничего не принял.

Сообщение от AncientPenguin

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

понимаете в чем ваш косяк:
под "отловить" подразумевают ловушку: catch, которая внезапно ловит исключения.

а не установление факта сбоя исполнителем.

и обрабатываться эта ситуация должна там же,
где её отловили - в той самой ловушке.

Сообщение от AncientPenguin

А где доказательства что функция myvec.at(100500); не вызвала еще функцию,

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

все, что вам надлежит знать, что бы пользоваться - это её интерфейс.

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

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

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

@AncientPenguin · 19.08.2015, 13:32

Сообщение от hoggy

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

Ну возможно, хотя мне кажется не все ученые страстно желают оказаться правыми.

Сообщение от hoggy

понимаете в чем ваш косяк:
под "отловить" подразумевают ловушку: catch, которая внезапно ловит исключения.

Двусмысленно согласен, однако

C++
1
2
3
4
if(arg < 0) // <--- поймали
{
    throw new Exception();
}

Тем более в первом сообщении я использовал глагол "выбросить".

Сообщение от hoggy

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

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

@hoggy · 19.08.2015, 14:39

Сообщение от AncientPenguin

считается ли место где вызвана эта функция тем же самым местом где образовалась ошибка

да.

различайте точки:
где приключилась авария.
место фиксации факта аварии.
точка восстановления после паники.

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

@AncientPenguin · 19.08.2015, 15:42

Сообщение от hoggy

да.

Сообщение от hoggy

на этажах выше уже вряд ли помогут.

Я в первом сообщении юникодом по аштиэмэлю написал:

Сообщение от AncientPenguin

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

Не на том же этаже исключение выброшено.

@mymedia · 20.08.2015, 08:42

Не по теме:

Сообщение от AncientPenguin

C++
1
2
3
4
if(arg < 0) // <--- поймали
{
    throw new Exception();
}

Внимание! Это вам не C#, вы бросили указатель на исключение, а не само исключение!

Сообщение от AncientPenguin

Я в первом сообщении юникодом по аштиэмэлю написал

:D :D . Внезапно киберфорум использует win-1251

Новые блоги и статьи Все статьи Все блоги /
сукцессия 29. Переход от одних деревьев на другие делать более или менее вероятностным? anaschu 12.07.2026 Насколько смена типов микоризы — исключительное событие в двухвековой сукцессии? Оценка вероятности в пространстве параметров В текущей версии модели успешно реализован ключевой механизм. . .	сукцессия 27. Думаю, как переделывать уже написанную статью с планами на сукцессию. anaschu 12.07.2026 Анализ соответствия модели требованиям Реализованные компоненты: Механизм закисления почвы через протонную помпу Конкуренция между типами микориз pH как триггер сукцессии C/ P соотношение. . .	Сукцессия 26. Мат модель создана. anaschu 12.07.2026 Модель смены растительных сукцессий посредством управления грибами работает внутри небольшой ячейки почвы, восстанавливающейся после пожара, где ненадолго бывшее царство хвойных снова захватили. . .	Решил проблему с ошибкой пагинации сообщений с сервера на алгоритме обхода дерева "Эстафета хвоста". Hrethgir 12.07.2026 Проблема была в том, что удалялась именно новая кнопка, а не старая. Ни один ИИ не обнаружил это, а сам я смог только когда с работой стало попроще и когда заставил работать будущее автономное. . .
сукцессия 25. Хронология ошибок anaschu 12.07.2026 # От 50-тонного гриба до устойчивого леса: хроника ошибок при построении модели вековой сукцессии микоризы ## О чём эта статья В процессе построения ОДУ-модели (система дифференциальных. . .	сукцессия 24. Промежуточное общее описание модели anaschu 12.07.2026 Хендофф: модель АМ→ЭКМ сукцессии микоризы (ризосфера, 50 лет) Содержание проекта Симуляция вековой (50 лет) экологической сукцессии в почве леса Основные участники: АМ-гриб, ЭКМ-гриб,. . .	сукцессия 23. Более физиологичная физиология, более экологичная экология, более диффурные диффуры. anaschu 12.07.2026 Что реально нашли и починили за эти 5 часов Правило Линдемана (КПД конверсии сахара в тело, kEff) — раньше 100% полученного углерода шло прямо в биомассу гриба; теперь только kEff=0. 5 (после. . .	сукцессия 22. От артефактов к физиологии: калибровка агентной модели грибной сукцессии для воспроизведения сезонной динамики и pH-плато anaschu 11.07.2026 Аннотация В данной работе представлена калибровка агентной модели динамики грибных сообществ (fungal-succession), направленная на устранение нефизичных артефактов (коллапс биомассы, мгновенное. . .