Кто что может сказать о технологии локализации исключений?

Question

[Mercury13]

Самый удобный способ объявить об ошибке в точке А и среагировать на это в точке Б — исключения. Но они плохо работают с технологиями локализации и интернационализации. Например, в библиотеке общего назначения может не быть библиотеки локализации.
Как вообще вы локализуете аварии? При первой возможности превращаете в LocalizedException (а в высокоспециализированном коде — наследуетесь от LocalizedException, да и всё)? Придумываете, как локализовать, только когда надо вывести сообщение на экран? Как-нибудь ещё?

UPD. Зачёл решение интересному собеседнику, хоть задача решена и частично.

Answer 1

[Денис Загаевский]

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

Comments

[Mercury13]

Хорошо, как вы поступаете с такими «нормальными ситуациями»? Даже если вы программируете на Java, предложите подход, никаких проблем не будет переписать их на другой язык.

[Mercury13]

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

Не соглашусь. Например, в Java есть три типа аварий.
• RuntimeException, по идее, вообще не должны вылетать (и если вылетит — с программой что-то серьёзное).
• Error — виртуальная машина чувствует себя плохо, и программу, по-хорошему, надо прикрыть.
• Все остальные — проблемы с окружением программы (например, нет файла). И проверяются, поскольку считаются нормальным ходом выполнения.

[Денис Загаевский]

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

[Mercury13]

Хорошо, вот код. На границе чужой библиотеки (LibXl) и специализированного кода.

AutoLibXl book(im::createXlsx());
    bool isOk = book->load(aFname);
    if (!isOk) {
        // Turn “Unknown exception” to localized message
        const char* errMsg = book->errorMessage();
        if (strcmp(errMsg, "Unknown exception") == 0) {
            throw WideException(loc::get("Error.CannotXlsx"));
        } else {
            throw WideException(str::u2w(errMsg));
        }
    }

[Mercury13]

Или вот самое простое.

QSqlDatabase im::openQdb(const im::QdbSettings::Conn& aSets)
{
    QSqlDatabase r;
    switch (aSets.type) {
    case im::QdbType::ODBC:
        r = QSqlDatabase::addDatabase("QODBC");
        r.setConnectOptions("SQL_ATTR_ODBC_VERSION=SQL_OV_ODBC3");
        break;
    case im::QdbType::MYSQL:
        r = QSqlDatabase::addDatabase("QMYSQL");
        r.setHostName(QString::fromStdWString(aSets.myHost));
        r.setPort(aSets.myPort);
        break;
    default:
        throw std::logic_error("Invalid SQL type, shouldn't happen normally");
    }
    r.setDatabaseName(QString::fromStdWString(aSets.dataset));
    if (!r.open(QString::fromStdWString(aSets.userName),
                QString::fromStdWString(aSets.password)))
        throw WideException(Wprintf(loc::get("Error.DbCantOpen"))
                (r.lastError().text()));
    return r;
}

[Денис Загаевский]

Mercury13: если хочется это пробросить до нужного места, надо кидать CustomLibXlException. Где-то там выше - ловить и решать, что надо показать. Но никак не глубоко в слое бизнес-логики решать, что увидит юзер.

[Денис Загаевский]

Mercury13: моё мнение - надо кидать два разных типа в этих случаях.

[Mercury13]

Хорошо, дело у нас самое простое — вывести модальное окошко. Как написать код преобразования нашего ECustomLibXl в сообщение для пользователя — с учётом того, что в Си++ нет «метаклассов» и кода наподобие

std::wstring customLibXlToWstring() {}
registerLocalizer(ECustomLibXl, customLibXlToWstring);

[Денис Загаевский]

Mercury13: Вообще, подобный код написать на С++ можно, было бы желание. Я не знаю вашу архитектуру и что вы используете, как я вам могу рассказать, какой код надо написать?

[Mercury13]

И ещё одна проблема — код выброса аварии и код регистрации преобразователя будут разнесены далеко-далеко, и сложно отслеживать незадействованные строки в ресурсе локализации.

[Денис Загаевский]

Mercury13: Это уже совсем другая проблема. К сожалению, я не знаю, какими средствами она решается в мире С++. Могу посоветовать только вместо ключей-строк использовать статические поля некоего класса, которые будут маппиться на ключи. Это, кстати, даёт ещё плюсы в виде того, что вы в ключе не опечатаетесь. Примерно так в андроиде устроен класс R, где лежат айдишники всех ресурсов. Но он генерится автоматически.

[Mercury13]

В обработчике события Qt мы пишем

try {
   // сделай что-то
} Q_CATCH_MB (this, loc::getQ("Error.HeadImport"))

Разумеется, в макросе Q_CATCH_MB мы не можем сделать поддержку каждой возможной аварии. И из-за раздувания кода, и из-за повторов в каждом catch-блоке, и из-за того, что большой кусок кода вносится в макрос. Приходится обходиться двумя-тремя catch-блоками, а каким методом преобразовывать текст в строку — решать уже какой-нибудь функцией, которая знает все возможные аварии и что с ними делать.

[Mercury13]

Далее, процентов 60 аварий выглядят как простейшее преобразование «класс → строка». С этим-то что делать? Опять-таки, не зависящее от компилятора имя класса в Си++ не получишь.

[Mercury13]

Я, конечно, зачту задачу интересному собеседнику. Хоть она решена и частично.

[Денис Загаевский]

Mercury13: опять же - это архитектурные проблемы, имхо. У меня таких проблем не бывает, потому что я так не делаю.

[Mercury13]

На данный момент вопросы у меня такие.
1. Не хочется раздувать макросы наподобие Q_CATCH_MB → приходится налаживать регистрацию аварий.
2. Нет метаклассов, нет компиляторонезависимых имён → непонятно, как наладить простенькую таблицу «класс-строка». Как я уже говорил, 60% фильтров будут выглядеть так.

std::wstring filterMyException(const std::exception& e)
{
   if (!dynamic_cast<MyException*>(&e))
     return std::wstring();
  return loc::get("Error.MyException");
}

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

[Mercury13]

И ещё вопрос. В другой программе (на Delphi) я просто передавал текстом аварии код языкового ресурса. Как вы относитесь к этому делу?

[Mercury13]

Денис Загаевский:

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

А тут вы откровенно переврали меня: я же сказал, что нет файла — это нормальная ситуация и в Java проверяются только такие «нормальные» аварии.

[Денис Загаевский]

>Непонятно, как синхронизировать строки в коде и языковых ресурсах

>И ещё вопрос. В другой программе (на Delphi) я просто передавал текстом аварии код языкового ресурса. Как вы относитесь к этому делу?

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

Кстати, в С++ наверняка есть best practice на эту тему, я-то не настоящий сварщик.

[Денис Загаевский]

>я же сказал, что нет файла — это нормальная ситуация и в Java проверяются только такие «нормальные» аварии.

Проверяемые исключения - это та ещё спорная вещь в джаве, не хотелось бы углубляться в это.
Так уж сложилось, что у меня нет необходимости замаппить тип исключения в строку и показать пользователю. Чаще всего нужно сделать что-то ещё, и это что-то зависит от типа исключения. Решается декомпозиций, у меня просто нет одного корня, куда прилетает всё со всей программы. Точнее есть, называется UncaughtExceptionHandler, и оттуда исключение отправляется в Fabric(Crashlytics), и вот там точно не надо, чтобы исключения были локализованные - они подклеиваются друг к другу и можно понять масштабы проблемы относительно количества пользователей. Нативные(С++) исключения тоже валятся туда.

[Денис Загаевский]

Нет метаклассов, нет компиляторонезависимых имён → непонятно, как наладить простенькую таблицу «класс-строка»

try {
} catch(MyException& e) {
......
} catch(MyOtherException& e) {
......
} catch(std::exception& e) {
......
} catch(...) {
......
}

Это первое, что приходит на ум.

[Mercury13]

Денис Загаевский:
Ну я же сказал: не хочется раздувать макрос.

[Mercury13]

Денис Загаевский:

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

Понимаю, и разбирать причины и последствия — офтоп. Просто факт: проверяются те, что возникают при нормальном ходе программы.

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

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

[Mercury13]

Денис Загаевский: Нелокализуемые строки, возникающие при нормальном ходе программы, есть. Наобум помню вот что.
1. Редчайшие ошибки (скажем, проблемы с форматом XLS/XLSX, часть ошибок cURL). Из-за того, что их практически невозможно протестировать, и никакой переводчик не поймёт, что писать. Поддержка XLS собственная, XLSX — пока нет, и, сказать честно, откровенно задрала. Если облом что-то делать — сажусь за собственную. Может, этак полгода спустя выкачу.
2. В классификации товаров по влиянию на оборот (A/B/C/D). Вряд ли подлежат переводу.
3. Знак бесконечности (товары, чей срок хранения не задан).
4. Запятая в значении «какая-то сумма, USD». Если строку USD вытащить не удалось — обходимся надписью «какая-то сумма».
5. Плюс в строках «+1», «+2», «+3» — если автоматика не нашла закономерности в датах и не смогла продолжить временной ряд дальше.
6. Ошибки, которые приходят с чужих серверов. Что, в принципе, логично.
7. Часть строк в поддержке зарубежных бухгалтерских систем. Ыгы, в США, Канаде и Австралии есть по своей «жёлтой» — скажем, в США она зелёная. Намеренно срезанный угол. Другая часть — локализованы «один в один».
8. Жёстко закодированный формат «20 %». Цифра 20, разумеется, форматируется по локали.