Здравствуйте, Zhendos, Вы писали:

vsb>>checked exceptions, как и result могут быть полезны как один из инструментов для написания своего кода. Очень редкий инструмент, я сколько пишу, так и не нашел, где это могло бы быть полезно. Ну теоретически могу представить функцию, вызывая которую ошибку обработать надо вообще абсолютно всегда, без исключений (простите за каламбур). Иначе там реактор взорваться может. Там это оправдано — заставлять вызывающего функцию обработать ошибку.

Z>Ну вообще во всех местах где пользователю показывают результат работы функции,
Z>неважно в каком виде: веб страница, desktop GUI, stdout нужен не backtrace,
Z>и какое-то невнятное сообщение, а сообщение о том что случилось и как это исправить.
Z>Для это и нужно контролировать прохождение ошибки сверху вниз и добавлять к ней нужный
Z>контекст.

И где ты это видел? Везде показывают "Ой, что-то случилось". Да и какое пользователю дело до сообщения? Ну потратишь ты год времени на то, чтобы пользователю написало красивым русским языком — "У нас кончилось место на диске и мы не смогли закоммитить транзакцию" или "Сервис Google Maps вернул ошибку, которая, вероятно, связана с отозванным токеном". И что дальше? Всё, что действительно нужно — это информативная ошибка в логе, по которой девопс сможет как можно быстрей понять причину и устранить или передать разработчикам. И эта информативная ошибка называется стектрейс. Всё, что нужно программисту — иногда добавлять к этому стектрейсу контекстную информацию. Чтобы потом проще было понять, что случилось. URL, какой-нибудь ID объекта, который мы пытались вставить и тд.

Здравствуйте, Zhendos, Вы писали:

vsb>>checked exceptions, как и result могут быть полезны как один из инструментов для написания своего кода. Очень редкий инструмент, я сколько пишу, так и не нашел, где это могло бы быть полезно. Ну теоретически могу представить функцию, вызывая которую ошибку обработать надо вообще абсолютно всегда, без исключений (простите за каламбур). Иначе там реактор взорваться может. Там это оправдано — заставлять вызывающего функцию обработать ошибку.

Z>Ну вообще во всех местах где пользователю показывают результат работы функции,
Z>неважно в каком виде: веб страница, desktop GUI, stdout нужен не backtrace,
Z>и какое-то невнятное сообщение, а сообщение о том что случилось и как это исправить.
Z>Для это и нужно контролировать прохождение ошибки сверху вниз и добавлять к ней нужный
Z>контекст.

И где ты это видел? Везде показывают "Ой, что-то случилось". Да и какое пользователю дело до сообщения? Ну потратишь ты год времени на то, чтобы пользователю написало красивым русским языком — "У нас кончилось место на диске и мы не смогли закоммитить транзакцию" или "Сервис Google Maps вернул ошибку, которая, вероятно, связана с отозванным токеном". И что дальше? Всё, что действительно нужно — это информативная ошибка в логе, по которой девопс сможет как можно быстрей понять причину и устранить или передать разработчикам. И эта информативная ошибка называется стектрейс. Всё, что нужно программисту — иногда добавлять к этому стектрейсу контекстную информацию. Чтобы потом проще было понять, что случилось. URL, какой-нибудь ID объекта, который мы пытались вставить и тд.

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