async fetchSomethingOrEmptyList() {
    try {
        return await fetch(`/foo-bar`)
    } catch (e) {
        return [];
    }
}

fetchSomethingOrEmptyList() {
    return fetch(`/foo-bar`).catch(() => [])
}

хотя вот так делать не надо. Пусть вываливается ошибка.

да и не все исключения в джаве чект

не тебе судить какой контракт удобнее для юзкейса

Вопрос выше был про разницу result object и checked exception

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

У них будут все те-же минусы, что у Result, но не будет плюсов что есть у Result.

есть кейсы, когда должна, но они единичные и должны быть дополнительные проверки на конкретную ошибку, а не тупо catch()

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

если это вообще ошибка а не "бэкэндщик тоже молодец и возвращает 500 если запись не найдена"

как будет, если ты ее словил?)

как того требует ситуация

да какая разница какая ошибка? Если <= 299, то ее нужно как-то обработать, и в 99% случаев это сентри и какой-то обобщенный еррор для юзера. Надо кастом - пожалуйста, лови конкретную ошибку которую ты ожидаешь и пляши, а остальное оставь общему обработчику

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

прям захотелось на этих ваших растах попесать, чтоб понять в чём разница 🤔

Чаще всего нормальная ситуация как раз. Залогировать и деградировать функционал, оставив основной функционал рабочим

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

И тут он идет в саппорт и начинает орать, куда же пропали его айтемы, вместо того, что бы изначально увидеть какой-нить "oops, something went wrong. Please, contact support".

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

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

какой понос? Вполне конкретная и реальная ситуация.

Я не предлагаю игнорировать ошибки, я предлагаю обрабатывать их ЦЕНТРАЛИЗОВАНО, а не в каждом конкретном юс кейсе. Приложение падать не будет.

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