LINUX.ORG.RU

История изменений

Исправление RazrFalcon, (текущая версия) :

Здесь уже зашит единственный тип возможной ошибки.

Ну так это пример. Ни кто не мешает написать:

enum Error {
    ParseError(std::num::ParseIntError),
    // любые другие типы ошибок
}

impl From<std::num::ParseIntError> for Error {
    fn from(err: std::num::ParseIntError) -> Error {
        Error::ParseError(err)
    }
}

fn myfunc() -> Result<u32, Error> {
...
}

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

Как по мне

Аргументированно.

С чего бы?

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

Пример:

static void test()
{
    throw "qwe";
}

int main(int argc, char *argv[])
{
    QCoreApplication a(argc, argv);

    try {
        QtConcurrent::run(test);
    } catch (...) {
        qDebug() << "lol";
    }

    return a.exec();
}

Исходная версия RazrFalcon, :

Здесь уже зашит единственный тип возможной ошибки.

Ну так это пример. Ни кто не мешает написать:

enum Error {
    ParseError(std::num::ParseIntError),
    // любые другие типы ошибок
}

impl From<std::num::ParseIntError> for Error {
    fn from(err: std::num::ParseIntError) -> Error {
        Error::ParseError(err)
    }
}

fn myfunc() -> Result<u32, Error> {
...
}

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

Как по мне

Аргументированно.

С чего бы?

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

Пример:

static void test()
{
    throw "qwe";
}

int main(int argc, char *argv[])
{
    QCoreApplication a(argc, argv);

    try {
        QtConcurrent::run(test);
    } catch (...) {
        qDebug() << "lol";
    }

    return a.exec();
}