Я вот посмотрел сейчас более подробно на musl. Судя по всему он более современный и менее совместимый с приложениями-старичками. Тут таблица сравнения. Допустим мы ей верим. Тогда
Из неё видно, что например однобайтовые локали плохо мюсли поддерживаются, зато utf-8 свой родной. Ну и хрен бы, честно говоря, с этими старыми локалями. Линукс и все более-менее развивающиеся проекты давно перешли на utf-8, и правильно сделали. И то, что в glibc это работает медленно совсем не в её пользу.
Также лучшая обработка внештатных ситуаций, о чём собственно статья.
Вопреки тому, что утверждает @Apoheliy, ссылаясь на википедию, поддержка платформы PC-x64 вполне на уровне.
Очевидные недостатки: страдает regexp, и возможно, не хватает POSIX localedef; нет отладки, т.е. я не смогу лог добыть как сделал в данном случае. Хотя в случае glibc это пока что мало помогло.
В моём случае Хром собрал две обвязки для Qt5 и Qt6 (упомянутая out/default/libqt5_shim.so и libqt6_shim.so) с использованием локально поставленного в каталог исходников корня системы Дебиан, указав при сборке путь до этого корня (--sysroot=../../build/linux/debian_bullseye_amd64-sysroot). Т.е. сборка именно libqt*_shim.so была выполнена относительно выкачанной дебиановской системы. При этом основная сборка вроде всё-таки на системные либы полагалась, там где не собирала своё (а в хроме своих локальных версий много).
В том то и дело, что если ограничиться проверкой только входных данных, то внутреннее состояние не контролируется. Это работает, если либа идеальна и без ошибок. Но такого не бывает. Так хоть бы определяли ошибки на более раннем этапе. Я ведь так и не выяснил, где же был баг в загрузчике. Удовлетворился пока тем, что в версии 2.32 работает (но это не точно, вернее не точно, что всегда).
Насчёт systemd-nspawn, не уверен, что есть в федоре. Хотя вот есть некий systemd-container. Пока что я запустился в чруте с федора-33, не знаю, насколько это будет стабильно для хрома. Да и в самой 28-й системе вроде можно теперь запустить, если убрать причину сбоя - удалить libqt5_shim.so.
Но предварительно указатель на массив можно проверить на ноль ведь? Там кстати есть проверка на ноль уже в теле, но поскольку элемент не первый, то указатель уже не ноль. Смешно.
Я работал с версией 2.27, не 2.17. Сборку делал на машине Fedora-28 (всё стандартное). Хромиум мне потенциально нужен для использования в своём проекте
Это StorageException, и вы умеете их обрабатывать, потому что это не конкретные исключения, а одно общее.
А если не умеете, то вакансий дворников и официантов много.
checked exceptions созданы, чтобы их обработать. Очевидно, что сервис и контроллер — независимые слои, прокидывать ошибки между ними напрямую нельзя, выкидывать из контроллера любую ошибку — тоже. Поэтому, ОБРАБАТЫВАЙТЕ. Я не буду пользоваться вашим сервисом, кидающим наружу ошибку коннекта к БД.
Боже мой, да это просто аналогия. Зовите, как хотите. Я к тому, что никто не запрещает, а даже рекомендует вам писать StorageException в сигнатуре метода. И не важно Амазон он или нет.
Есть у вас StorageException — его и кидайте, и сделайте проверяемым. А всю остальную гирлянду уберите.
Во-первых, это мой конкретный случай, где от результата операции зависит, что я далее буду делать. Во-вторых, это не сторадж, а запуск докер контейнеров, и там требований больше чем просто сохранить. В-третьих, у меня есть целый слой, работающий с ресурсами и их взаимосвязями, поэтому используется своя логика в т.ч. при инициализации ресурсов.
К слову, NotFoundException, NotModifiedException используются только в данном конкретном поставщике ресурсов. В других поставщиках я знать ничего не хочу про эти ошибки, они не относятся к верхнеуровневой логике. Но и просто падать тоже нельзя. Я вообще удивляюсь, почему такая базовая вещь вызывает вопросы. Возможно, стоит пройти курсы повышения квалификации? Или, например, пройти сертификационный экзамен?
Я сказал, как делать правильно в первом пункте в статье. Статья вообще не про правильные подходы, а как упростить синтаксис правильных подходов. Если будет возможность/желание написать именно про обработку ошибок, можно это организовать. Хотя я уверен, по этому поводу уже много написано. Правда то, что на Хабре представлено, я не считаю верными подходами.
Ваш IStorage это *.sql.Connection. И там прекрасно объявлены SQLException. Так что не нельзя, а нужно.
Ну такая уж у меня система, полмесяца назад вообще была f24
Я вот посмотрел сейчас более подробно на musl. Судя по всему он более современный и менее совместимый с приложениями-старичками.
Тут таблица сравнения. Допустим мы ей верим. Тогда
Из неё видно, что например однобайтовые локали плохо мюсли поддерживаются, зато utf-8 свой родной. Ну и хрен бы, честно говоря, с этими старыми локалями. Линукс и все более-менее развивающиеся проекты давно перешли на utf-8, и правильно сделали. И то, что в glibc это работает медленно совсем не в её пользу.
Также лучшая обработка внештатных ситуаций, о чём собственно статья.
Вопреки тому, что утверждает @Apoheliy, ссылаясь на википедию, поддержка платформы PC-x64 вполне на уровне.
Очевидные недостатки: страдает regexp, и возможно, не хватает POSIX localedef; нет отладки, т.е. я не смогу лог добыть как сделал в данном случае. Хотя в случае glibc это пока что мало помогло.
В моём случае Хром собрал две обвязки для Qt5 и Qt6 (упомянутая out/default/libqt5_shim.so и libqt6_shim.so) с использованием локально поставленного в каталог исходников корня системы Дебиан, указав при сборке путь до этого корня (--sysroot=../../build/linux/debian_bullseye_amd64-sysroot). Т.е. сборка именно libqt*_shim.so была выполнена относительно выкачанной дебиановской системы.
При этом основная сборка вроде всё-таки на системные либы полагалась, там где не собирала своё (а в хроме своих локальных версий много).
В том то и дело, что если ограничиться проверкой только входных данных, то внутреннее состояние не контролируется. Это работает, если либа идеальна и без ошибок. Но такого не бывает. Так хоть бы определяли ошибки на более раннем этапе. Я ведь так и не выяснил, где же был баг в загрузчике. Удовлетворился пока тем, что в версии 2.32 работает (но это не точно, вернее не точно, что всегда).
аналогично
Тут есть нюансы.
Мне нужен именно свой хром, буду его ковырять. Хотя неофициальные образы тоже есть
Мне на период разработки всё-таки желательно с графикой чтоб было
Насчёт systemd-nspawn, не уверен, что есть в федоре. Хотя вот есть некий systemd-container.
Пока что я запустился в чруте с федора-33, не знаю, насколько это будет стабильно для хрома.
Да и в самой 28-й системе вроде можно теперь запустить, если убрать причину сбоя - удалить libqt5_shim.so.
А тут, между прочим, ещё один пример последствий отсутсвия проверок
Кстати, по поводу альтернатив Хабр тут вовремя предложил статью-сравнение мюсли и гну
https://habr.com/ru/articles/520920/
Но предварительно указатель на массив можно проверить на ноль ведь? Там кстати есть проверка на ноль уже в теле, но поскольку элемент не первый, то указатель уже не ноль. Смешно.
Я работал с версией 2.27, не 2.17.
Сборку делал на машине Fedora-28 (всё стандартное).
Хромиум мне потенциально нужен для использования в своём проекте
Адрес точнее - этот: https://sourceware.org/glibc/
-
Оно интерактивное?
Нет.
Опять 25. Я устал.
Это StorageException, и вы умеете их обрабатывать, потому что это не конкретные исключения, а одно общее.
А если не умеете, то вакансий дворников и официантов много.
checked exceptions созданы, чтобы их обработать. Очевидно, что сервис и контроллер — независимые слои, прокидывать ошибки между ними напрямую нельзя, выкидывать из контроллера любую ошибку — тоже. Поэтому, ОБРАБАТЫВАЙТЕ. Я не буду пользоваться вашим сервисом, кидающим наружу ошибку коннекта к БД.
Боже мой, да это просто аналогия. Зовите, как хотите. Я к тому, что никто не запрещает, а даже рекомендует вам писать StorageException в сигнатуре метода. И не важно Амазон он или нет.
Есть у вас StorageException — его и кидайте, и сделайте проверяемым. А всю остальную гирлянду уберите.
Во-первых, это мой конкретный случай, где от результата операции зависит, что я далее буду делать. Во-вторых, это не сторадж, а запуск докер контейнеров, и там требований больше чем просто сохранить. В-третьих, у меня есть целый слой, работающий с ресурсами и их взаимосвязями, поэтому используется своя логика в т.ч. при инициализации ресурсов.
К слову, NotFoundException, NotModifiedException используются только в данном конкретном поставщике ресурсов. В других поставщиках я знать ничего не хочу про эти ошибки, они не относятся к верхнеуровневой логике. Но и просто падать тоже нельзя. Я вообще удивляюсь, почему такая базовая вещь вызывает вопросы. Возможно, стоит пройти курсы повышения квалификации? Или, например, пройти сертификационный экзамен?
Я сказал, как делать правильно в первом пункте в статье. Статья вообще не про правильные подходы, а как упростить синтаксис правильных подходов. Если будет возможность/желание написать именно про обработку ошибок, можно это организовать. Хотя я уверен, по этому поводу уже много написано. Правда то, что на Хабре представлено, я не считаю верными подходами.
Ваш IStorage это *.sql.Connection. И там прекрасно объявлены SQLException. Так что не нельзя, а нужно.
ПС: Вы всегда можете проверить корректность восприятия исключений в Джава, попробовав сдать соответствующие экзамены: https://alexmanrique.com/blog/development/2018/11/25/oca-certified.html