C вывод ошибки try catch

Обработка исключений

Конструкция try..catch..finally

Последнее обновление: 30.12.2021

Иногда при выполнении программы возникают ошибки, которые трудно предусмотреть или предвидеть, а иногда и вовсе невозможно. Например, при передачи файла по сети может неожиданно оборваться сетевое подключение.
такие ситуации называются исключениями. Язык C# предоставляет разработчикам возможности для обработки таких ситуаций. Для этого
в C# предназначена конструкция try…catch…finally.

try
{
	
}
catch
{
	
}
finally
{
	
}

При использовании блока try…catch..finally вначале выполняются все инструкции в блоке try. Если в
этом блоке не возникло исключений, то после его выполнения начинает выполняться блок finally. И затем конструкция try..catch..finally
завершает свою работу.

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

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

Рассмотрим следующий пример:

int x = 5;
int y = x / 0;
Console.WriteLine($"Результат: {y}");
Console.WriteLine("Конец программы");

В данном случае происходит деление числа на 0, что приведет к генерации исключения. И при запуске приложения в
режиме отладки мы увидим в Visual Studio окошко, которое информирует об исключении:

В этом окошке мы видим, что возникло исключение, которое представляет тип System.DivideByZeroException,
то есть попытка деления на ноль. С помощью пункта View Details можно посмотреть более детальную информацию об исключении.

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

Чтобы избежать подобного аварийного завершения программы, следует использовать для обработки исключений конструкцию
try…catch…finally. Так, перепишем пример следующим образом:

try
{
	int x = 5;
	int y = x / 0;
	Console.WriteLine($"Результат: {y}");
}
catch
{
	Console.WriteLine("Возникло исключение!");
}
finally
{
	Console.WriteLine("Блок finally");
}
Console.WriteLine("Конец программы");

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

int y = x / 0;

выполнение программы остановится. CLR найдет блок catch и передаст управление этому блоку.

После блока catch будет выполняться блок finally.

Возникло исключение!
Блок finally
Конец программы

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

Следует отметить, что в этой конструкции обязателен блок try. При наличии блока catch мы можем опустить блок finally:

try
{
	int x = 5;
	int y = x / 0;
	Console.WriteLine($"Результат: {y}");
}
catch
{
	Console.WriteLine("Возникло исключение!");
}

И, наоборот, при наличии блока finally мы можем опустить блок catch и не обрабатывать исключение:

try
{
	int x = 5;
	int y = x / 0;
	Console.WriteLine($"Результат: {y}");
}
finally
{
	Console.WriteLine("Блок finally");
}

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

Обработка исключений и условные конструкции

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

Square("12"); // Квадрат числа 12: 144
Square("ab"); // !Исключение

void Square(string data)
{
    int x = int.Parse(data);
    Console.WriteLine($"Квадрат числа {x}: {x * x}");
}

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

Square("12"); // Квадрат числа 12: 144
Square("ab"); // Некорректный ввод

void Square(string data)
{
    if (int.TryParse(data, out var x))
    {
        Console.WriteLine($"Квадрат числа {x}: {x * x}");
    }
    else
    {
        Console.WriteLine("Некорректный ввод");
    }
}

Метод int.TryParse() возвращает true, если преобразование можно осуществить, и false — если нельзя. При допустимости преобразования переменная x
будет содержать введенное число. Так, не используя try...catch можно обработать возможную исключительную ситуацию.

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

Время прочтения
4 мин

Просмотры 12K

Всё началось с безобидного пролистывания GCC расширений для C. Мой глаз зацепился за вложенные функции. Оказывается, в C можно определять функции внутри функций:

int main() {
    void foo(int a) {
        printf("%dn", a);
    }
    for(int i = 0; i < 10; i ++)
        foo(i);
    return 0;
}

Более того, во вложенных функциях можно менять переменные из внешней функции и переходить по меткам из неё, но для этого необходимо, чтобы переменные были объявлены до вложенной функции, а метки явно указаны через __label__

int main() {
    __label__ end;
    int i = 1;

    void ret() {
        goto end;
    }
    void inc() {
        i ++;
    }
    
    while(1) {
        if(i > 10)
            ret();
        printf("%dn", i);
        inc();
    }

  end:
    printf("Donen");
    return 0;
}

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

Приступим к написанию try-catch. Определим вспомогательные типы данных:

// Данными, как и выкинутой ошибкой может быть что угодно
typedef void *data_t;
typedef void *err_t;

// Определяем функцию для выкидывания ошибок
typedef void (*throw_t)(err_t);

// try и catch. Они тоже будут функциями
typedef data_t (*try_t)(data_t, throw_t);
typedef data_t (*catch_t)(data_t, err_t);

Подготовка завершена, напишем основную функцию. К сожалению на хабре нельзя выбрать отдельно язык C, поэтому будем писать try_, catch_, throw_ чтобы их подсвечивало как функции, а не как ключевые слова C++

data_t try_catch(try_t try_, catch_t catch_, data_t data) {
    __label__ fail;
    err_t err;
    // Объявляем функцию выбрасывания ошибки
    void throw_(err_t e) {
        err = e;
        goto fail;
    }
    // Передаём в try данные и callback для ошибки
    return try_(data, throw_);
    
  fail:
    // Если есть catch, передаём данные, над которыми 
    // работал try и ошибку, которую он выбросил
    if(catch_ != NULL)
        return catch_(data, err);
    // Если нет catch, возвращаем пустой указатель
    return NULL;
}

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

data_t try_sqrt(data_t ptr, throw_t throw_) {
    float *arg = (float *)ptr;
    if(*arg < 0)
        throw_("Error, negative numbern");
  
    // Выделяем кусок памяти для результата
    float *res = malloc(sizeof(float));
    *res = sqrt(*arg);
    return res;
}

data_t catch_sqrt(data_t ptr, err_t err) {
    // Если возникла ошибка, печатает её и ничего не возвращаем
    fputs(err, stderr);
    return NULL;
}

Добавляем функцию main, посчитаем в ней корень от 1 и от -1

int main() {
    printf("------- sqrt(1) --------n");
    float a = 1;
    float *ptr = (float *) try_catch(try_sqrt, catch_sqrt, &a);

    if(ptr != NULL) {
        printf("Result of sqrt is: %fn", *ptr);
        // Не забываем освободить выделенную память
        free(ptr);
    } else
        printf("An error occuredn");
    

    printf("------- sqrt(-1) -------n");
    a = -1;
    ptr = (float *)try_catch(try_sqrt, catch_sqrt, &a);

    if(ptr != NULL) {
        printf("Result of sqrt is: %fn", *ptr);
        // Аналогично
        free(ptr);
    } else
        printf("An error occuredn");
  
    return 0;
}

И, как и ожидалось, получаем

------- sqrt(1) --------
Result of sqrt is: 1.000000
------- sqrt(-1) -------
Error, negative number
An error occured

Try-catch готов, господа.

На этом статью можно было бы и закончить, но тут внимательный читатель заметит, что функция throw остаётся валидной в блоке catch. Можно вызвать её и там, и тогда мы уйдём в рекурсию. Заметим также, что функция throw, это не обычная функция, она noreturn и разворачивает стек, поэтому, даже если вызвать её в catch пару сотен раз, на стеке будет только последний вызов. Мы получаем хвостовую оптимизацию рекурсии.

Попробуем посчитать факториал на нашем try-catch. Для этого передадим указатель на функцию throw в функцию catch. Сделаем это через структуру, в которой также будет лежать аккумулятор вычислений.

struct args {
    uint64_t acc;
    throw_t throw_;
};

В функции try инициализируем поле throw у структуры, и заводим переменную num для текущего шага рекурсии.

data_t try_(data_t ptr, throw_t throw_) {
    struct args *args = ptr;
    // Записываем функцию в структуру, чтобы catch мог её pf,hfnm
    args->throw_ = throw_;
  
    // Заводим переменную для хранения текущего шага рекурсии
    uint64_t *num = malloc(sizeof(uint64_t));
    // Изначально в acc лежит начальное число, в нашем случае 10
    *num = args->acc; 
    // Уменьшаем число
    (*num) --;
    // Уходим в рекурсию
    throw_(num);
}

В функции catch будем принимать структуру и указатель на num, а дальше действуем как в обычном рекурсивном факториале.

data_t catch_(data_t ptr, err_t err) {
    struct args *args = ptr;
    // В err на самом деле лежит num
    uint64_t *num = err;
    // Печатаем num, будем отслеживать рекурсию
    printf("current_num: %"PRIu64"n", *num);
    
    if(*num > 0) {
        args->acc *= *num;
        (*num) --;
        // Рекурсивный вызов
        args->throw_(num);
    }
    // Конец рекурсии
    // Не забываем осовободить выделенную память
    free(num);
    
    // Выводим результат
    printf("acc is: %"PRIu64"n", args->acc);
    return &args->acc;
}

int main() {
    struct args args = { .acc = 10 };
    try_catch(try_, catch_, &args);

    return 0;
}

Вызываем, и получаем, как и ожидалось:

current_num: 9
current_num: 8
current_num: 7
current_num: 6
current_num: 5
current_num: 4
current_num: 3
current_num: 2
current_num: 1
current_num: 0
acc is: 3628800

main.c

#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <inttypes.h>
#include <stdnoreturn.h>

typedef void *err_t;
typedef void *data_t;
typedef void (*throw_t)(err_t);
typedef data_t (*try_t)(data_t, throw_t);
typedef data_t (*catch_t)(data_t, err_t);


data_t try_catch(try_t try, catch_t catch, data_t data) {
    __label__ fail;
    err_t err;
    void throw(err_t e) {
        err = e;
        goto fail;
    }

    return try(data, throw);
    
  fail:
    if(catch != NULL)
        return catch(data, err);
    return NULL;
}

struct args {
    uint64_t acc;
    throw_t throw_;
};

data_t try_(data_t ptr, throw_t throw_) {
    struct args *args = ptr;
    args->throw_ = throw_;

    uint64_t *num = malloc(sizeof(uint64_t));
    *num = args->acc;
    (*num) --;
    
    throw_(num);
}

data_t catch_(data_t args_ptr, err_t num_ptr) {
    struct args *args = args_ptr;
    uint64_t *num = num_ptr;
    
    printf("current_num: %"PRIu64"n", *num);
    
    if(*num > 0) {
        args->acc *= *num;
        (*num) --;
        args->throw_(num);
    }
    free(num);
    printf("acc is: %"PRIu64"n", args->acc);
    return &args->acc;
}

int main() {
    struct args args = { .acc = 10 };
    try_catch(try_, catch_, &args);

    return 0;
}

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

P.S. Текст попытался вычитать, но, так как русского в школе не было, могут быть ошибки. Прошу сильно не пинать и по возможности присылать всё в ЛС, постараюсь реагировать оперативно.

An exception is a blocking error.

First of all, the best practice should be don’t throw exceptions for any kind of error, unless it’s a blocking error.

If the error is blocking, then throw the exception. Once the exception is already thrown, there’s no need to hide it because it’s exceptional; let the user know about it (you should reformat the whole exception to something useful to the user in the UI).

Your job as software developer is to endeavour to prevent an exceptional case where some parameter or runtime situation may end in an exception. That is, exceptions mustn’t be muted, but these must be avoided.

For example, if you know that some integer input could come with an invalid format, use int.TryParse instead of int.Parse. There is a lot of cases where you can do this instead of just saying «if it fails, simply throw an exception».

Throwing exceptions is expensive.

If, after all, an exception is thrown, instead of writing the exception to the log once it has been thrown, one of best practices is catching it in a first-chance exception handler. For example:

• ASP.NET: Global.asax Application_Error
• Others: AppDomain.FirstChanceException event.

My stance is that local try/catches are better suited for handling special cases where you may translate an exception into another, or when you want to «mute» it for a very, very, very, very, very special case (a library bug throwing an unrelated exception that you need to mute in order to workaround the whole bug).

For the rest of the cases:

• Try to avoid exceptions.
• If this isn’t possible: first-chance exception handlers.
• Or use a PostSharp aspect (AOP).

Answering to @thewhiteambit on some comment…

@thewhiteambit said:

Exceptions are not Fatal-Errors, they are Exceptions! Sometimes they
are not even Errors, but to consider them Fatal-Errors is completely
false understanding of what Exceptions are.

First of all, how an exception can’t be even an error?

• No database connection => exception.
• Invalid string format to parse to some type => exception
• Trying to parse JSON and while input isn’t actually JSON => exception
• Argument null while object was expected => exception
• Some library has a bug => throws an unexpected exception
• There’s a socket connection and it gets disconnected. Then you try to send a message => exception
• …

We might list 1k cases of when an exception is thrown, and after all, any of the possible cases will be an error.

An exception is an error, because at the end of the day it is an object which collects diagnostic information — it has a message and it happens when something goes wrong.

No one would throw an exception when there’s no exceptional case. Exceptions should be blocking errors because once they’re thrown, if you don’t try to fall into the use try/catch and exceptions to implement control flow they mean your application/service will stop the operation that entered into an exceptional case.

Also, I suggest everyone to check the fail-fast paradigm published by Martin Fowler (and written by Jim Shore). This is how I always understood how to handle exceptions, even before I got to this document some time ago.

[…] consider them Fatal-Errors is completely false understanding of what exceptions are.

Usually exceptions cut some operation flow and they’re handled to convert them to human-understandable errors. Thus, it seems like an exception actually is a better paradigm to handle error cases and work on them to avoid an application/service complete crash and notify the user/consumer that something went wrong.

More answers about @thewhiteambit concerns

For example in case of a missing Database-Connection the program could
exceptionally continue with writing to a local file and send the
changes to the Database once it is available again. Your invalid
String-To-Number casting could be tried to parse again with
language-local interpretation on Exception, like as you try default
English language to Parse(«1,5») fails and you try it with German
interpretation again which is completely fine because we use comma
instead of point as separator. You see these Exceptions must not even
be blocking, they only need some Exception-handling.

1. If your app might work offline without persisting data to database, you shouldn’t use exceptions, as implementing control flow using try/catch is considered as an anti-pattern. Offline work is a possible use case, so you implement control flow to check if database is accessible or not, you don’t wait until it’s unreachable.

2. The parsing thing is also an expected case (not EXCEPTIONAL CASE). If you expect this, you don’t use exceptions to do control flow!. You get some metadata from the user to know what his/her culture is and you use formatters for this! .NET supports this and other environments too, and an exception because number formatting must be avoided if you expect a culture-specific usage of your application/service.

An unhandled Exception usually becomes an Error, but Exceptions itself
are not codeproject.com/Articles/15921/Not-All-Exceptions-Are-Errors

This article is just an opinion or a point of view of the author.

Since Wikipedia can be also just the opinion of articule author(s), I wouldn’t say it’s the dogma, but check what Coding by exception article says somewhere in some paragraph:

[…] Using these exceptions to handle specific errors that arise to
continue the program is called coding by exception. This anti-pattern can quickly degrade software in performance and maintainability.

It also says somewhere:

Incorrect exception usage

Often coding by exception can lead to further issues in the software
with incorrect exception usage. In addition to using exception
handling for a unique problem, incorrect exception usage takes this
further by executing code even after the exception is raised. This
poor programming method resembles the goto method in many software
languages but only occurs after a problem in the software is detected.

Honestly, I believe that software can’t be developed don’t taking use cases seriously. If you know that…

• Your database can go offline…
• Some file can be locked…
• Some formatting might be not supported…
• Some domain validation might fail…
• Your app should work in offline mode…
• whatever use case…

…you won’t use exceptions for that. You would support these use cases using regular control flow.

And if some unexpected use case isn’t covered, your code will fail fast, because it’ll throw an exception. Right, because an exception is an exceptional case.

In the other hand, and finally, sometimes you cover exceptional cases throwing expected exceptions, but you don’t throw them to implement control flow. You do it because you want to notify upper layers that you don’t support some use case or your code fails to work with some given arguments or environment data/properties.

An exception is a blocking error.

First of all, the best practice should be don’t throw exceptions for any kind of error, unless it’s a blocking error.

If the error is blocking, then throw the exception. Once the exception is already thrown, there’s no need to hide it because it’s exceptional; let the user know about it (you should reformat the whole exception to something useful to the user in the UI).

Your job as software developer is to endeavour to prevent an exceptional case where some parameter or runtime situation may end in an exception. That is, exceptions mustn’t be muted, but these must be avoided.

For example, if you know that some integer input could come with an invalid format, use int.TryParse instead of int.Parse. There is a lot of cases where you can do this instead of just saying «if it fails, simply throw an exception».

Throwing exceptions is expensive.

If, after all, an exception is thrown, instead of writing the exception to the log once it has been thrown, one of best practices is catching it in a first-chance exception handler. For example:

• ASP.NET: Global.asax Application_Error
• Others: AppDomain.FirstChanceException event.

My stance is that local try/catches are better suited for handling special cases where you may translate an exception into another, or when you want to «mute» it for a very, very, very, very, very special case (a library bug throwing an unrelated exception that you need to mute in order to workaround the whole bug).

For the rest of the cases:

• Try to avoid exceptions.
• If this isn’t possible: first-chance exception handlers.
• Or use a PostSharp aspect (AOP).

Answering to @thewhiteambit on some comment…

@thewhiteambit said:

Exceptions are not Fatal-Errors, they are Exceptions! Sometimes they
are not even Errors, but to consider them Fatal-Errors is completely
false understanding of what Exceptions are.

First of all, how an exception can’t be even an error?

• No database connection => exception.
• Invalid string format to parse to some type => exception
• Trying to parse JSON and while input isn’t actually JSON => exception
• Argument null while object was expected => exception
• Some library has a bug => throws an unexpected exception
• There’s a socket connection and it gets disconnected. Then you try to send a message => exception
• …

We might list 1k cases of when an exception is thrown, and after all, any of the possible cases will be an error.

An exception is an error, because at the end of the day it is an object which collects diagnostic information — it has a message and it happens when something goes wrong.

No one would throw an exception when there’s no exceptional case. Exceptions should be blocking errors because once they’re thrown, if you don’t try to fall into the use try/catch and exceptions to implement control flow they mean your application/service will stop the operation that entered into an exceptional case.

Also, I suggest everyone to check the fail-fast paradigm published by Martin Fowler (and written by Jim Shore). This is how I always understood how to handle exceptions, even before I got to this document some time ago.

[…] consider them Fatal-Errors is completely false understanding of what exceptions are.

Usually exceptions cut some operation flow and they’re handled to convert them to human-understandable errors. Thus, it seems like an exception actually is a better paradigm to handle error cases and work on them to avoid an application/service complete crash and notify the user/consumer that something went wrong.

More answers about @thewhiteambit concerns

For example in case of a missing Database-Connection the program could
exceptionally continue with writing to a local file and send the
changes to the Database once it is available again. Your invalid
String-To-Number casting could be tried to parse again with
language-local interpretation on Exception, like as you try default
English language to Parse(«1,5») fails and you try it with German
interpretation again which is completely fine because we use comma
instead of point as separator. You see these Exceptions must not even
be blocking, they only need some Exception-handling.

1. If your app might work offline without persisting data to database, you shouldn’t use exceptions, as implementing control flow using try/catch is considered as an anti-pattern. Offline work is a possible use case, so you implement control flow to check if database is accessible or not, you don’t wait until it’s unreachable.

2. The parsing thing is also an expected case (not EXCEPTIONAL CASE). If you expect this, you don’t use exceptions to do control flow!. You get some metadata from the user to know what his/her culture is and you use formatters for this! .NET supports this and other environments too, and an exception because number formatting must be avoided if you expect a culture-specific usage of your application/service.

An unhandled Exception usually becomes an Error, but Exceptions itself
are not codeproject.com/Articles/15921/Not-All-Exceptions-Are-Errors

This article is just an opinion or a point of view of the author.

Since Wikipedia can be also just the opinion of articule author(s), I wouldn’t say it’s the dogma, but check what Coding by exception article says somewhere in some paragraph:

[…] Using these exceptions to handle specific errors that arise to
continue the program is called coding by exception. This anti-pattern can quickly degrade software in performance and maintainability.

It also says somewhere:

Incorrect exception usage

Often coding by exception can lead to further issues in the software
with incorrect exception usage. In addition to using exception
handling for a unique problem, incorrect exception usage takes this
further by executing code even after the exception is raised. This
poor programming method resembles the goto method in many software
languages but only occurs after a problem in the software is detected.

Honestly, I believe that software can’t be developed don’t taking use cases seriously. If you know that…

• Your database can go offline…
• Some file can be locked…
• Some formatting might be not supported…
• Some domain validation might fail…
• Your app should work in offline mode…
• whatever use case…

…you won’t use exceptions for that. You would support these use cases using regular control flow.

And if some unexpected use case isn’t covered, your code will fail fast, because it’ll throw an exception. Right, because an exception is an exceptional case.

In the other hand, and finally, sometimes you cover exceptional cases throwing expected exceptions, but you don’t throw them to implement control flow. You do it because you want to notify upper layers that you don’t support some use case or your code fails to work with some given arguments or environment data/properties.

Overview

Exceptions are used to indicate that an error has occurred while running the program. Exception objects that describe an error are created and then thrown with the throw keyword. The runtime then searches for the most compatible exception handler.

In C# language’s exception handling features helps to deal with any unexpected or exceptional situations that occur when a program is running. Exception handling uses the
try, catch, and finally keywords to

• Try actions that may not succeed
• To handle failures when decided that it is reasonable to do so
• To clean up resources afterwards

and Exceptions can be generated

• By the common language runtime (CLR)
• By the .NET Framework or any third-party libraries
• Or by application code

Exceptions are created by using the
throw keyword.

↑ Return to
Top

Syntax

An error can occur at almost any statement. Checking for all these errors becomes unbearably complex. Exception handling separates this logic. It simplifies control flow. C# exception handling is built upon four keywords:
try, catch, finally, and
throw.

The try block encloses the statements that might throw an exception whereas catch handles an exception if one exists. The finally can be used for doing any clean up process. The general form of try-catch-finally in C# is shown below.

↑ Return to
Top

Uncaught Exception

The following program will compile but will show an error during execution. The division by zero is a runtime anomaly and the program terminates with an error message. Any uncaught exceptions in the current context propagate to a higher context and looks
for an appropriate catch block to handle it. If it can’t find any suitable catch blocks then the default mechanism of the .NET runtime will terminate the execution of the entire program.

Code

Output

↑ Return to
Top

Handling Exception

In C# it provides a structured solution for the exception handling in the form of try and catch blocks. Using these blocks the core program statements are separated from the error-handling statements. As we see from the above example it can’t find any suitable
catch blocks then the default mechanism of the .NET runtime will terminate the execution of the entire program. To prevent this from happening we modified the above program with error handling blocks. These are implemented with
try, catch keywords. So, the modified form with the exception handling mechanism is as follows.

Code

Output

↑ Return to
Top

Throwing Exception

It is possible to throw an exception programmatically. throw is basically like throwing an exception from that point, so the stack trace would only go to where we are issuing the «throw». This throwing exception is handled by catch block.
The throw statement is used for this purpose. The general form of throwing an exception is as follows.

Code

Output

↑ Return to
Top

Exception Bubbling

In the above examples, we saw that Exception is handled in the catch block. Where main() method runs the code and raised exception is handled in the catch block. Imagine the situation what happens if there are multiple nested function calls, and exception
occurred in the fourth or fifth nested call.

• Function1(): Calls Function2 within the try block and handles the exception in catch block
• Function2(): Makes a call to the function Function3. But it neither wraps the call for Function3 in the try block nor has the exception handler
• Function3(): Makes a call to the function Function4. But it neither wraps the call for Function4 in the try block nor has the exception handler
• Function4(): Makes a call to the function Function5. But it neither wraps the call for Function5 in the try block nor has the exception handler
• Function5(): Raises an Exception

Code

Output

Explanation

Modified Code

Output

If we comment out the finally block in Function5() code will goto to the finally block in the main() method in backward.

Explanation

Here we can see that there is an exception handling mechanism implemented in the
Function5 so code is not going backward to find catch block and filling the stack. As exception is handled there code is then going backward to
finally block in main() and returning successfully from each function.

↑ Return to
Top

Summary

By now, we should have good understanding of what is an exception bubbling. An Exception will be caught in the inner catch block if appropriate filter found, otherwise will be
caught by outer catch block. We can implement
try/ catch block to prevent exception to bubbling up. Also we know how to clean up resources by implementing a
finally block whose code is always executed before leaving a method.

↑ Return to
Top

Reference

• Exception Handling Fundamentals
  here
• Best Practices for Exceptions
  here
• Exception Handling Statements
  here
• Handling and Throwing Exceptions
  here
• Managing Exceptions with the Debugger
  here

↑ Return to
Top

See Also

• Exception
  Handling Best Practices in .NET
• Best
  Practices — Exception Handling in C# .NET
• How
  using try catch for exception handling is best practice

↑ Return to
Top

Download

Download the Source Code used in the example from this link
Download Source Code

↑ Return to
Top

При разработке программного обеспечения мало составить и реализовать какой-либо алгоритм, важно также предусмотреть всевозможные непредвиденные ситуации при работе вашей программы и, в случае необходимости отловить и обработать исключения, которые могут возникнуть. Например, вы решили разработать программу-клиент для работы с блогом, которая позволяет публиковать статьи, модерировать комментарии и выполнять прочую полезную работу. Как бы вы не старались сделать свое приложение работоспособным, неизбежно, при работе с программой пользователь может столкнуться с такими проблемами: сайт недоступен (например, в результате ошибки сервера 5хх), не возможно соединиться с базой данных и так далее. В любом из этих случаев, без должной обработки исключений, ваша программа будет аварийно завершать работу и пугать пользователей сообщениями об ошибках. Сегодня мы рассмотрим некоторые моменты по обработке исключений в C#.

Рассмотрим канонический пример того, когда работа с программой приводит к генерации исключения — деление на ноль. Вот такой может быть наша программа:

Console.WriteLine("Введите любое целое число и нажмите Enter");
int i = int.Parse(Console.ReadLine());
double x = 5;
double y = x / i;
Console.WriteLine($"{x}/{i}={y}");

Теперь запустим программу и введем  число 0. В итоге, в Visual Studio мы увидим ошибку:

Мы получили исключение типа System.DivideByZeroException (деление на ноль) и наше приложение аварийно завершило свою работу. Кроме этого, в таком простом, казалось бы, приложении имеется ещё одна уязвимость — пользователь может ввести совсем не то, что от него требуется и вместо числа введет, например, строку. В этом случае мы, опять же, получим в Visual Studio исключение:

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

Блок try…catch…finally

Для обработки исключений в C# используется специальная конструкция — блок try...catch...finally. Перепишем наше приложение следующим образом:

Console.WriteLine("Введите любое целое число и нажмите Enter");
try
{
    int i = int.Parse(Console.ReadLine());
    int x = 5;
    double y = x / i;
    Console.WriteLine($"{x}/{i}={y}");
}
catch
{
    Console.WriteLine("Неправильный ввод значения");
}
finally
{
    Console.WriteLine("Выполнили блок finally");
}
_ = Console.ReadLine();

Теперь запустим программу и снова введем значение 0. В результате, программа не завершит работу аварийно, а выведет в консоль сообщение. Вот вывод консоли:

Приложение так же, как и в предыдущем примере, дошло до строки

double y = x / i;

однако, вместо аварийной остановки на строке с ошибкой, программа перешла в блок catch и вывела сообщение «Неправильный ввод значения». После того, как выполнен блок catch, программа переходит в блок finally, выполняет все операции в нем и завершает работу.

В конструкции try...catch...finally обязательным является блок try. Блоки catch или finally могут отсутствовать, при этом следует отметить, что, если отсутствует блок catch, то исключение будет возбуждено и программа аварийно завершит работу. Варианты использования конструкции try...finally...catch могут быть такими:

//БЕЗ БЛОКА FINALLY. Программа не завершается аварийно
try
{
    int i = int.Parse(Console.ReadLine());
    int x = 5;
    double y = x / i;
    Console.WriteLine($"{x}/{i}={y}");
}
catch
{
    Console.WriteLine("Неправильный ввод значения");
}

или

//БЕЗ БЛОКА CATCH. Программа аварийно завершит работу
try
{
    int i = int.Parse(Console.ReadLine());
    int x = 5;
    double y = x / i;
    Console.WriteLine($"{x}/{i}={y}");
}
finally
{
    Console.WriteLine("Выполнили блок finally");
}

Блок finally обычно используется для выполнения очистки ресурсов выделенных в блоке try.  Блок finally не выполниться в том случае, если в блоке catch также, как и в try возникнет какое-либо исключение.

Перехват и обработка исключений в блоке catch

В примере с блоком catch выше всё, что мы сделали — это вывели одно сообщение о том, что пользователь ввел неверное значение. При этом, при разработке реальных приложений часто необходимо не только сообщить пользователю об исключении, но и постараться направить его на «путь истинный». Например, в нашем тестовом приложении пользователь, как мы определили может:

1. ввести 0 (исключение System.DivideByZeroException)
2. ввести вместо целого числа строку (исключение System.FormatException)
3. ввести вместо целого числа число с плавающей запятой (исключениеSystem.FormatException)
4. ввести число, превышающее максимальное значение int (исключение System.OverflowException)

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

try
{
    i = int.Parse(Console.ReadLine());
    
    double y = x / i;
    Console.WriteLine($"{x}/{i}={y}");
}
catch (System.DivideByZeroException e)
{
    Console.WriteLine($"Деление на ноль! Исключение {e}");
}
catch (System.FormatException e)
{
    Console.WriteLine($"Введено не целое число! Исключение {e}");
}
catch (System.OverflowException e)
{
    Console.WriteLine($"Введите число в диапазоне от {int.MinValue} до {int.MaxValue}, исключая ноль. Исключение {e}");
}

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

Следует также отметить, что далеко не всегда удается на этапе разработки предугадать абсолютна все типы исключений. Что, например, произойдет, если мы уберем из нашего кода блок, обрабатывающий System.OverflowException? Правильно, мы снова нарвемся на аварийное завершение работы программы, так как компилятор пройдет по всем блокам catch и не сможет соотнести тип исключение с именем.  Чтобы такого не произошло, можно также предусмотреть при обработке исключений общий блок catch в котором будет обрабатываться всё, что не попало в другие блоки. Например, мы можем сделать обработку двух типов исключений, а третий — обработаем в общем блоке:

catch (System.OverflowException e)
{
    Console.WriteLine($"Введите число в диапазоне от {int.MinValue} до {int.MaxValue}, исключая ноль. Исключение {e}");
}


catch (System.DivideByZeroException e)
{
    Console.WriteLine($"Деление на ноль! Исключение {e}");
}
//общий блок catch
catch
{
    Console.WriteLine("Неизвестная ошибка. Перезапустите программу");
}

Необходимо отметить, что важен не только факт наличия, но и порядок написания блоков catch. Универсальный блок catch должен находиться в самом низу кода. Об этом, кстати, Visual Studio сообщает. Если вы перенесете общий блок catch и поставите его, например, над блоком, обрабатывающим исключение DivideByZeroException, то Visual Studio выдаст ошибку:

Логические операции и обработка исключений в C#

Несмотря на то, что использование конструкции try..catch..finally прекрасно позволяет перехватывать и обрабатывать различного типа исключения, её использование не всегда может быть оправдано, а некоторые исключения могут быть предвидены разработчиком и обработаны с использованием обычных логических операций. Например, в случае, если пользователь вводит не число, а непонятно что, можно было бы обойтись вот такой конструкцией:

if (int.TryParse(Console.ReadLine(), out i))
{
    y = x / i;
    Console.WriteLine($"{x}/{i}={y}");
}    
else
{
    Console.WriteLine("Вы ввели не число!");
}

Здесь метод int.TryParse() пробует преобразовать строку в целое число и, если преобразование прошло успешно, то возвращает true. Таким образом, мы избежали использования конструкции try...catch, которая, кстати, с точки зрения производительности более накладна, чем обычный условный оператор if.

Итого

Сегодня мы познакомились с тем, как перехватывать и обрабатывать исключения в C#. Научились обрабатывать определенные типы исключений и в правильном порядке расставлять блоки catch в коде. Иногда мы можем повысить производительность нашего приложения, заменив, где это возможно и оправданно, конструкции try...catch на обычные логические операции, например, используя условный оператор if.