¿
Возможно redis тебе подойдёт
Я для otp как раз редис использую - очень удобно
кто-то может подсказать сервисы для сбора логов, на подобии sentry?
и что по поводу денег, надо ли где-то оформлять подписки и все такое
Size: a a a
2020 September 06
2020 September 07
OV
кто-то может подсказать сервисы для сбора логов, на подобии sentry?
и что по поводу денег, надо ли где-то оформлять подписки и все такое
и что по поводу денег, надо ли где-то оформлять подписки и все такое
Т
Господа, я тут на ровном месте развел в нескольких местах холивары на такую вот тему. Если метод возвращает null, это норм или не норм?
AV
Господа, я тут на ровном месте развел в нескольких местах холивары на такую вот тему. Если метод возвращает null, это норм или не норм?
зачем это нужно?
Т
Я вот придерживаюсь что не норм. Хотелось бы услышать ещё мнения.
Т
зачем это нужно?
Так вышло...
Т
Ну его мнение я знаю и с ним согласен:)
AV
Так вышло...
Если нет аргументации зачем метод возвращает null, то какие холивары могут быть? 🤔
Т
Если нет аргументации зачем метод возвращает null, то какие холивары могут быть? 🤔
Ну типа ничего не нашел, а шото вернуть надо
TS
Господа, я тут на ровном месте развел в нескольких местах холивары на такую вот тему. Если метод возвращает null, это норм или не норм?
Это то же самое, что утверждать, что никогда нельзя ничего передавать через глобал, просто потому, что нельзя.
TS
Нельзя лезть во внутренние данные чужих модулей, ни как, ни через глобал, ни через рекваер (что то же самое), ни через синглтон, ни через ивент-эмиттер, ни через передачу их в методы/функции по ссылке. Это правда. Нужно общаться между модулями через интерфейсы. А как вы передаете интерфейсы, через глобал, через инхекцию, рекваер, ивент-эмитером или как угодно - не важно.
TS
Точто так же и с null, если идти на принцип бездумно, то тогда нужно и от undefined отказаться.
TS
И вообще перейти на монаду Either
TS
Но мы же не сектанты. Кому-то лучше делать кортеж из ошибки и результата { error, result } или [error, result], кому-то нужно сделать класс/прототип такой контейнер для результата new Result { onSuccess, onFail }, кому-то промисами можно.
TS
Но избавиться от if-ов по обработке ошибок принципиально невозможно, их можно только скрыть за абстракциями, вынести из бизнес-логики, чтобы очистить минтаксим куска кода и повысить его читаемость, чтобы этот if не писать по 10 раз в разных частях приложения, но он все равно будет где-то.
TS
null-object это вообще дичайший антипаттерн, это костыль + все if-ы остаются. Если уж прятать null/undefined и error, то за контейнерами, функциональными или обектными, но универсальными контейнерами. А null-object для каждого класса отдельный контейнер еще генерирует - маразм же
A
null-object это вообще дичайший антипаттерн, это костыль + все if-ы остаются. Если уж прятать null/undefined и error, то за контейнерами, функциональными или обектными, но универсальными контейнерами. А null-object для каждого класса отдельный контейнер еще генерирует - маразм же
А если простыми словами, можно ли считать что метод должен возвращать результат по контракту?
A
Полагаю Немчинский скорей всего имел в виду это в контексте организации архитектурного кода в Java (ЯП со строгой типизацией). Предполагаю что при обработке результатов могут быть всякого рода ошибки и не очевидные результаты.
TS
В джаве тоже не нужны null-object, там тоже можно делать универсальные контейнеры.