Ms
Хм, даже Фил
Size: a a a
2021 November 18
Ms
А трудовую новую завел?
PD
Ко мне в последнее время примерно так же приходят )
Ms
PD
А как еще умножать-то?
Конечно можно интринсики сделать, но не так надежно, да и интринсики нормальные появились попозже.
Конечно можно интринсики сделать, но не так надежно, да и интринсики нормальные появились попозже.
PD
Да, это чуть ли не самое прекрасное, что я видел.
На хабре, кстати, был подробный разбор.
На хабре, кстати, был подробный разбор.
PD
Ну, вообще системных достаточно для большей части приложений.
Концепция checked exception оказалась не очень удачной.
Но я вообще не видел пока хорошего решения для работы с ошибками (
Концепция checked exception оказалась не очень удачной.
Но я вообще не видел пока хорошего решения для работы с ошибками (
РИ
Ну так вот если есть инструмент - им сразу хочется попользоваться
PD
Ну, в Java сделать Result можно было хоть в 1.1
Не монадой, конечно, но для многих целей - нормально.
Я первый раз в 1.4 делал.
Не монадой, конечно, но для многих целей - нормально.
Я первый раз в 1.4 делал.
PD
Использовать исключения для передачи управления - все-таки фу.
PD
Там больше проблем, когда и исключения и async или корутины (
M
Исключения - для исключительных ситуаций.
Пользователь ты имеешь ввиду кто? Конечный пользователь или пользователь твоего кода (фреймворка)?
Пользователь ты имеешь ввиду кто? Конечный пользователь или пользователь твоего кода (фреймворка)?
PD
Неа. Так как интересен полный список всех возможных исключений по стеку вызовов, а его в большинстве языков не построить (да и вызовы могут быть сложносочиненными через reflection).
PD
Были альтернативы. Но индустрия всегда выбирает наихудшие из возможных варианты (
PD
Технически - запихать в restful можно что угодно.
Но очень неудобно делать все бизнес-операции, затрагивающие несколько объектов (онбординг, например), сложные выборки (когда в query не влезает), запросы с ПДН (так как не могут быть GET), изменения сущностей со сложной семантикой (когда "смена статуса", "смена фио" и "смена адреса" - это три разных бизнес-операции).
Но очень неудобно делать все бизнес-операции, затрагивающие несколько объектов (онбординг, например), сложные выборки (когда в query не влезает), запросы с ПДН (так как не могут быть GET), изменения сущностей со сложной семантикой (когда "смена статуса", "смена фио" и "смена адреса" - это три разных бизнес-операции).
AB
Ну да, конечно же с допущением, что автор учел в своем коде, мир не идеален. На практике проверку от компилера на обработку всех исключений не оч хотелось бы, по крайней мере опционально.
PD
Заметим, в терминах ресурсов и ровно 5 операций.
В ООП нет ресурсов, есть объекты и обрабатываемые ими сообщения. И нет доступа к внутренней структуре объекта.
В ООП нет ресурсов, есть объекты и обрабатываемые ими сообщения. И нет доступа к внутренней структуре объекта.
PD
Нет, запросы по RESTful - это только GET.
POST для получения данных - нарушение принципов.
POST для получения данных - нарушение принципов.
VF
Всмысле? Ну у тебя Библиотека и сеть отвалилась или сервак прислал что-то непонятное, как ты будешь это обрабатывать в библиотеке? Выкидываешь исключение и там уже пользователь решает чего он хочет делать
Ms
Ну как, есть исключения, для деструктивных операций (с серьезными сайд эффектами) лучше таки post