ŹR
А у тебя прилетел какой-нибудь null pointer exception и че
Size: a a a
2019 December 17
ЛЛ
Ну ты должен знать что ты ищешь
Ну конечно. Сервис запаниковал, прочитал трейс, почитал по логам что было до этого. И поправил. Не вижу ничего сложного.
ЛЛ
А у тебя прилетел какой-нибудь null pointer exception и че
Он тоже может прилететь и по стектрейсу видно где чё упало.
OJ
Ну ты должен знать что ты ищешь
Последний инцидент в конкретном сервисе за определенный промежуток времени согласно просадке в графике прометеуса скажем.
А если мы говорим про sentry, то он мержит все одинаковые ексепшены и на выхлопе на каждый сервис ты получаешь достаточно небольшую сводку
А если мы говорим про sentry, то он мержит все одинаковые ексепшены и на выхлопе на каждый сервис ты получаешь достаточно небольшую сводку
ЛЛ
Чем больше логов - тем труднее разгребать
Наоборот
OJ
А у тебя прилетел какой-нибудь null pointer exception и че
В го так не бывает.
Он в лог сразу высрет разрабу где ты неправ и кто ты после этого
Он в лог сразу высрет разрабу где ты неправ и кто ты после этого
ЛЛ
В го так не бывает.
Он в лог сразу высрет разрабу где ты неправ и кто ты после этого
Он в лог сразу высрет разрабу где ты неправ и кто ты после этого
Ну так сервис не падает - просто зависает в панике и всё.
ЛЛ
Открываешь логи - смотришь всё висит в панике. Посмотрел чё было до этого. Обработал ошибку. И всё.
ЛЛ
При написание тестов количество таких случаев стремиться к нулю.
OJ
Логичный Лесник
Ну так сервис не падает - просто зависает в панике и всё.
В большинстве случаев по панике лучше падать, кроме той которую бросаешь ты. Если сам выбрасываешь панику то нужно где-то ее рекаверить, другая проблема скажем в библиотеке которую ты используешь в цепочке вызовов бросается паника которую ты не ожидаешь в таком случае лучше падать и по always restart восстанавливаться.
ЛЛ
В большинстве случаев по панике лучше падать, кроме той которую бросаешь ты. Если сам выбрасываешь панику то нужно где-то ее рекаверить, другая проблема скажем в библиотеке которую ты используешь в цепочке вызовов бросается паника которую ты не ожидаешь в таком случае лучше падать и по always restart восстанавливаться.
Я сам не бросал паники, не приходилось. Кстати на счёт восстановления: https://blog.golang.org/defer-panic-and-recover простой пример
ЛЛ
Но опять же использовать не приходилось, проще обработать этот случай отдельно и написать комментарий в коде, чтобы снова не наступить на те же грабли.
ЛЛ
А так получается, что в любом случае ты должен знать где упадёшь, чтобы подстелить соломку и на сколько я понял, эрланг не исключение
ЛЛ
То есть ты вешаешь под супервизор те части, в которых ты сомневаешься.
OJ
Ну я про это и говорю, вот толко стоит понимать что рекавер ты не везде сможешь воткнуть
‘’’recover() can only be used inside deferred functions. If you call recover() during normal flow, it will simply return nil . ‘’’
‘’’recover() can only be used inside deferred functions. If you call recover() during normal flow, it will simply return nil . ‘’’
ЛЛ
Ну я про это и говорю, вот толко стоит понимать что рекавер ты не везде сможешь воткнуть
‘’’recover() can only be used inside deferred functions. If you call recover() during normal flow, it will simply return nil . ‘’’
‘’’recover() can only be used inside deferred functions. If you call recover() during normal flow, it will simply return nil . ‘’’
Ну в принципе логично.
ЛЛ
Simon Khaskelberg
Так по такой логике любой язык программирования вынуждает обрабатывать ошибки. И PHP тоже
Ну PHP отдельная история, там многие ошибки ты обработать не сможешь. И их придётся глушить 💩
V
Да всё там можно обработать
SK
Логичный Лесник
Ну PHP отдельная история, там многие ошибки ты обработать не сможешь. И их придётся глушить 💩
Например?
SK
Мне даже интересно стало, какие ошибки ты не сможешь обработать в PHP