История изменений
Исправление den73, (текущая версия) :
Да нет, это не я талант, это ведь ты говоришь, что defer-ы должны обрабатываться даже если случилось что-то реально плохое. Тут пример у меня не совсем удачный, т.к. считается хорошим тоном иметь пул соединение и вообще никогда не вызывать db.Close. Не говоря о том, насколько это плохо для сервера БД (невежливо отвалившиеся коннекты могут зависать и подвешивать всю базу или требовать ручного вмешательства), пул соединений вызывает другие вопросы: например, что делать, если возникла штатная ошибка (нарушение уникальности ключа), а за ней ошибка в rollback. Просто напечатать сообщение об этом в лог и продолжать работать - это явный способ огрести следующих проблем, поскольку мы вернём в пул коннект в явно неисправном состоянии и это скажется на следующем использовании этого коннекта.
Я уже принял для себя решение, что мой сервис будет отрабатывать без падения только определённое количество заранее известных ошибок. Всё непонятное будет приводить к выходу через os.Exit(n). А выдачу 500, если сервис лежит, видимо, должен будет обезпечивать какой-нибудь нгинкс. Пока не разбирался, как это делается.
Т.е. я не собираюсь исполнять эту рекомендацию о вызове defer-ов и меня это не коснётся, пока я хозяин своего кода. Когда буду не хозяин - будем брать под козырёк и разгребать говно, которое будет обязательно происходить от такого кривого подхода. Жаль только того, что мне приходится доходить до правильных решений самостоятельно, а официальные рекомендации вредоносны. На этом я теряю время.
Исправление den73, :
Да нет, это не я талант, это ведь ты говоришь, что defer-ы должны обрабатываться даже если случилось что-то реально плохое. Тут пример у меня не совсем удачный, т.к. считается хорошим тоном иметь пул соединение и вообще никогда не вызывать db.close. Не говоря о том, насколько это плохо для сервера БД (невежливо отвалившиеся коннекты могут зависать и подвешивать всю базу или требовать ручного вмешательства), пул соединений вызывает другие вопросы: например, что делать, если возникла штатная ошибка (нарушение уникальности ключа), а за ней ошибка в rollback. Просто напечатать сообщение об этом в лог и продолжать работать - это явный способ огрести следующих проблем, поскольку мы вернём в пул коннект в явно неисправном состоянии и это скажется на следующем использовании этого коннекта.
Я уже принял для себя решение, что мой сервис будет отрабатывать без падения только определённое количество заранее известных ошибок. Всё непонятное будет приводить к выходу через os.Exit(n). А выдачу 500, если сервис лежит, видимо, должен будет обезпечивать какой-нибудь нгинкс. Пока не разбирался, как это делается.
Т.е. я не собираюсь исполнять эту рекомендацию о вызове defer-ов и меня это не коснётся, пока я хозяин своего кода. Когда буду не хозяин - будем брать под козырёк и разгребать говно, которое будет обязательно происходить от такого кривого подхода. Жаль только того, что мне приходится доходить до правильных решений самостоятельно, а официальные рекомендации вредоносны. На этом я теряю время.
Исправление den73, :
Да нет, это не я талант, это ведь ты говоришь, что defer-ы должны обрабатываться даже если случилось что-то реально плохое. Тут пример у меня не совсем удачный, т.к. считается хорошим тоном иметь пул соединение и вообще никогда не вызывать db.close. Не говоря о том, насколько это плохо для сервера БД (невежливо отвалившиеся коннекты могут зависать и подвешивать всю базу или требовать ручного вмешательства), пул соединений вызывает другие вопросы: например, что делать, если возникла штатная ошибка (нарушение уникальности ключа), а за ней ошибка в rollback. Просто напечатать сообщение об этом в лог и продолжать работать - это явный способ огрести следующих проблем, поскольку мы вернём в пул коннект в явно неисправном состоянии и это скажется на следующем использовании этого коннекта.
Я уже принял для себя решение, что мой сервис будет отрабатывать без падения только определённое количество заранее известных ошибок. Всё непонятное будет приводить к выходу через os.Exit(n). А выдачу 500, если сервис лежит, видимо, должен будет обезпечивать какой-нибудь нгинкс. Пока не разбирался, как это делается.
Т.е. я не собираюсь исполнять эту рекомендацию о вызове defer-ов и меня это не коснётся, пока я хозяин своего кода. Когда буду не хозяин - будем брать под козырёк и разгребать говно, которое будет обязательно происходить от такого кривого подхода. Жаль только того, что мне приходится доходить до правильных решений самостоятельно, а официальные рекомендации вредоносны.
Исправление den73, :
Да нет, это не я талант, это ведь ты говоришь, что defer-ы должны обрабатываться даже если случилось что-то реально плохое. Тут пример у меня не совсем удачный, т.к. считается хорошим тоном иметь пул соединение и вообще никогда не вызывать db.close. Не говоря о том, насколько это плохо для сервера БД (невежливо отвалившиеся коннекты могут зависать и подвешивать всю базу или требовать ручного вмешательства), пул соединений вызывает другие вопросы: например, что делать, если возникла штатная ошибка (нарушение уникальности ключа), а за ней ошибка в rollback. Просто напечатать сообщение об этом в лог и продолжать работать - это явный способ огрести следующих проблем, поскольку мы вернём в пул коннект в явно неисправном состоянии и это скажется на следующем использовании этого коннекта.
Я уже принял для себя решение, что мой сервис будет отрабатывать без падения только определённое количество заранее известных ошибок. Всё непонятное будет приводить к выходу через os.Exit(n). А выдачу 500, если сервис лежит, видимо, должен будет обезпечивать какой-нибудь нгинкс. Пока не разбирался, как это делается.
Исправление den73, :
Да нет, это не я талант, это ведь ты говоришь, что defer-ы должны обрабатываться даже если случилось что-то реально плохое. Тут пример у меня не совсем удачный, т.к. считается хорошим тоном иметь пул соединение и вообще никогда не вызывать db.close. Не говоря о том, насколько это плохо для сервера БД (невежливо отвалившиеся коннекты могут зависать и подвешивать всю базу или требовать ручного вмешательства), пул соединений вызывает другие вопросы: например, что делать, если возникла штатная ошибка (нарушение уникальности ключа), а за ней ошибка в rollback. Просто напечатать сообщение об этом в лог и продолжать работать - это явный способ огрести следующих проблем, поскольку мы вернём в пул коннект в явно неисправном состоянии и это скажется на следующем использовании этого коннекта.
Я уже принял для себя решение, что мой сервис будет отрабатывать без падения только определённое количество заранее известных ошибок, а выдачу 500, если он сломался, видимо, должен будет обезпечивать какой-нибудь нгинкс. Пока не разбирался, как это делается.
Исходная версия den73, :
Да нет, это не я талант, это ведь ты говоришь, что defer-ы должны обрабатываться даже если случилось что-то реально плохое. Тут пример у меня не совсем удачный, т.к. считается хорошим тоном иметь пул соединение и вообще никогда не вызывать db.close. Не говоря о том, насколько это плохо для сервера БД (невежливо отвалившиеся коннекты могут зависать и подвешивать всю базу или требовать ручного вмешательства), пул соединений вызывает другие вопросы: например, что делать, если возникла штатная ошибка (нарушение уникальности ключа), а за ней ошибка в rollback. Просто напечатать сообщение об этом в лог и продолжать работать - это явный способ огрести следующих проблем, поскольку мы вернём в пул коннект в явно неисправном состоянии и это скажется на следующем использовании этого коннекта.