Разве try catch в dev библиотеках не затрудняет разработку?

[Megabyte]

Не могу не написать. Интересует ваше мнение.
Очень часто в dev версиях библиотек все обернуто в try catch, которое перехватывает ошибку и рисует ее в красивой красной рамочке с уточнением, что именно наша отважная библиотека перехватила ошибку в вашем коде секунду назад. Круто.
Но гараздо удобнее видеть ошибку в том месте где она произошла, с текущим стеком и всеми аргументами, непосредственно в момент выполнения упавшего кода. Это упрощает понимание происходящего.
Сегодня для эксперимента удалил try catch в react.dev.js и ошибки в render функциях стало очень удобно анализировать и исправлять.
Почему авторы библиотек не понимают что нужно для удобной разработки, а что для прода?
Если я не прав - прошу вразумить. Спасибо.

[ksa]

Megabyte, знаешь почему булочки продают по 3шт, а сосиски по 5шт?

[Megabyte]

Это первая мудрость пуленепробиваемого монаха. Но в моем вопросе это как поможет? : )

[ksa]

Но в моем вопросе это как поможет?

Это собственно и есть ответ на твой вопрос.

[Aetae]

Ответ: потому что жизнь - боль.
Я хз почему отладка реакта превращается в пляски с бубном. Мне постоянно не покидает чувство, что наверное я просто что-то не понимаю и делаю не так. Но нагуглить как делать "так" - тоже не получается...

[ksa]

Я хз почему отладка реакта превращается в пляски с бубном.

Я для себя сделал такое "наблюдение"... Нужно просто привыкнуть к сообщениям об ошибках на каком-либо языке (пришлось сменять несколько раз). Когда привыкаешь - становится понятно и разницы уже нет никакой.

Оно конечно, сложность программ у всех разная... Но я довольно быстро "разруливаю" проблемы в Реакте, с которыми обращаются мои сотрудники.
Как правило это они и являются источниками проблем.
Если все "разложить" на простые элементы/функции - все становится понятно.

[ksa]

Но нагуглить как делать "так" - тоже не получается...

Я сначала читаю книги по ЯП/библиотеки. Там более академично рассказывают принципы того или иного ЯП/библиотеки...
Если их придерживаться - проблем почти не возникает.

[Aetae]

ksa, вот например ошибки вида

Objects are not valid as a React child (found: object with keys {hasError, filesIds}). If you meant to render a collection of children, use an array instead.

пиздец неинформативные. Я понимаю что где-то прилетел объект вместо ReactNode. Но и только.
В стеке только куча внутреннего реакт мусора и примерное(очень, сука, примерное) имя компонента. Кодовая база - легаси, написанный криворучками на чистом js.
И вот как это диагностировать не тратя кучу времени на ручной перебор? Куда оно конкретно прилетело и откуда? Хз.
Простите за экспрессию.)

[ksa]

пиздец неинформативные

В одной книжке прочитал, что сообщения об ошибках в JS, помогают как стакан холодной воды в жаркий день для утопающего.

Так вот я с этим согласен.
Просто собираю свою "коллекцию" сообщений и "ситуаций". Это потом позволяет в диагностике "типичных" ситуаций.

Простите за экспрессию.)

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

[Megabyte]

ksa, вот например ошибки вида пиздец неинформативные. Я понимаю что где-то прилетел объект вместо ReactNode. Но и только.
В стеке только куча внутреннего реакт мусора и примерное(очень, сука, примерное) имя компонента. Кодовая база - легаси, написанный криворучками на чистом js.
И вот как это диагностировать не тратя кучу времени на ручной перебор? Куда оно конкретно прилетело и откуда? Хз.
Простите за экспрессию.)

Эта ошибка возникает в старом реакте без классов. Если компонентам проставить displayName, то сообщения об ошибках станут информативнее.

Как раз эту ошибку сложно отловить в месте возникновения, так как валидация происходит после выхода из метода. Тут бы пригодился механизм получения имени файла и строки в исходнике для произвольного метода. Например, вызвать метод с пустым this от чего он упадет, перехватить эту ошибку через try catch и из стека узнать местонахождение метода в коде.