История изменений
Исправление kaldeon, (текущая версия) :
Что значит «вызывающему было хорошо» я не вполне понимаю.
Указать в сообщении что произошло, чтобы вызывающему не пришлось быть чрезмерно многословным в пробрасывании ошибки. Например, os.Open/Read/Write/Close добавляют имя файла. Иногда вернуть частичную информацию (например, при чтении данных). Указать тип (или поведение через интерфейс), чтобы вызывающему было удобно среагировать. Если уместно, аггрегировать ошибки. Смысл в том, чтобы учитывать это заранее, в момент написания кода.
работать с СУБД с помощью транзакционных операций
Если повезёт, они будут. В некоторых их специально нет. При межсервисном общении тразакций нет по-умолчанию.
Тут хорошо подходит концепция трейсов.
Трейсы относительно обработки ошибок - как PostgreSQL относительно файлов. То есть не везде можно применить (не будешь же трейсы ставить на каждый вызов), несоразмерно сложнее в использовании и обслуживании.
Строка ошибки - идеальный баланс между ясностью (которую Go поощряет на всех уровнях) и простотой.
И если клиенту захочется разобраться - а что же случилось - он скажет нам идентификатор
- Ошибка может произойти на инфре клиента, доступ вряд ли дадут
- Идентификатор может протухнуть
Выплюнули строку из 20 символов и потом думай - что это такое.
Подумать, конечно, придётся. Однако, я не вижу что плохого в таких ошибках:
Server failed: initialize server: load config from /etc/myapp/config.json: open /etc/myapp/config.json: no such file or directory
Server failed: handle request for user 123: query user 123: sql: connection is already closed
Исправление kaldeon, :
Что значит «вызывающему было хорошо» я не вполне понимаю.
Указать в сообщении что произошло, чтобы вызывающему не пришлось быть чрезмерно многословным в пробрасывании ошибки. Например, os.Open/Read/Write/Close добавляют имя файла. Иногда вернуть частичную информацию (например, при чтении данных). Указать тип (или поведение через интерфейс), чтобы вызывающему было удобно среагировать. Если уместно, аггрегировать ошибки. Смысл в том, чтобы учитывать это заранее, в моменте формирования API.
работать с СУБД с помощью транзакционных операций
Если повезёт, они будут. В некоторых их специально нет. При межсервисном общении тразакций нет по-умолчанию.
Тут хорошо подходит концепция трейсов.
Трейсы относительно обработки ошибок - как PostgreSQL относительно файлов. То есть не везде можно применить (не будешь же трейсы ставить на каждый вызов), несоразмерно сложнее в использовании и обслуживании.
Строка ошибки - идеальный баланс между ясностью (которую Go поощряет на всех уровнях) и простотой.
И если клиенту захочется разобраться - а что же случилось - он скажет нам идентификатор
- Ошибка может произойти на инфре клиента, доступ вряд ли дадут
- Идентификатор может протухнуть
Выплюнули строку из 20 символов и потом думай - что это такое.
Подумать, конечно, придётся. Однако, я не вижу что плохого в таких ошибках:
Server failed: initialize server: load config from /etc/myapp/config.json: open /etc/myapp/config.json: no such file or directory
Server failed: handle request for user 123: query user 123: sql: connection is already closed
Исправление kaldeon, :
Что значит «вызывающему было хорошо» я не вполне понимаю.
Указать в сообщении что произошло, чтобы вызывающему не пришлось быть чрезмерно многословным в пробрасывании ошибки. Например, os.Open/Read/Write/Close добавляют имя файла. Иногда вернуть частичную информацию (например, при чтении данных). Указать тип (или поведение через интерфейс), чтобы вызывающему было удобно среагировать. Если уместно, аггрегировать ошибки. Смысл в том, чтобы делать это заранее, в моменте формирования API.
работать с СУБД с помощью транзакционных операций
Если повезёт, они будут. В некоторых их специально нет. При межсервисном общении тразакций нет по-умолчанию.
Тут хорошо подходит концепция трейсов.
Трейсы относительно обработки ошибок - как PostgreSQL относительно файлов. То есть не везде можно применить (не будешь же трейсы ставить на каждый вызов), несоразмерно сложнее в использовании и обслуживании.
Строка ошибки - идеальный баланс между ясностью (которую Go поощряет на всех уровнях) и простотой.
И если клиенту захочется разобраться - а что же случилось - он скажет нам идентификатор
- Ошибка может произойти на инфре клиента, доступ вряд ли дадут
- Идентификатор может протухнуть
Выплюнули строку из 20 символов и потом думай - что это такое.
Подумать, конечно, придётся. Однако, я не вижу что плохого в таких ошибках:
Server failed: initialize server: load config from /etc/myapp/config.json: open /etc/myapp/config.json: no such file or directory
Server failed: handle request for user 123: query user 123: sql: connection is already closed
Исправление kaldeon, :
Что значит «вызывающему было хорошо» я не вполне понимаю.
Указать в сообщении что произошло, чтобы вызывающему не пришлось быть чрезмерно многословным в пробрасывании ошибки. Например, os.Open/Read/Write/Close добавляют имя файла. Иногда вернуть частичную информацию (например, при чтении данных). Указать тип (или поведение через интерфейс), чтобы вызывающему было удобно среагировать. Если уместно, аггрегировать ошибки. Смысл в том, чтобы делать это заранее, в моменте формирования API.
работать с СУБД с помощью транзакционных операций
Если повезёт, они будут. В некоторых их специально нет. При межсервисном общении тразакций нет по-умолчанию.
Тут хорошо подходит концепция трейсов.
Трейсы относительно обработки ошибок - как PostgreSQL относительно файлов. То есть не везде можно применить (не будешь же трейсы ставить на каждый вызов), несоразмерно сложнее в использовании и обслуживании.
Строка ошибки - идеальный баланс между ясностью (которую Go поощряет на всех уровнях) и простотой.
И если клиенту захочется разобраться - а что же случилось - он скажет нам идентификатор
- Ошибка может произойти на инфре клиента, доступ вряд ли дадут
- Идентификатор может протухнуть
Выплюнули строку из 20 символов и потом думай - что это такое.
Подумать, конечно, придётся. Однако я не вижу что плохого в таких ошибках:
Server failed: initialize server: load config from /etc/myapp/config.json: open /etc/myapp/config.json: no such file or directory
Server failed: handle request for user 123: query user 123: sql: connection is already closed
Исправление kaldeon, :
Что значит «вызывающему было хорошо» я не вполне понимаю.
Указать в сообщении что произошло, чтобы вызывающему не пришлось быть чрезмерно многословным в пробрасывании ошибки. Например, os.Open/Read/Write/Close добавляют имя файла. Иногда вернуть частичную информацию (например, при чтении данных). Указать тип (или поведение через интерфейс), чтобы вызывающему было удобно среагировать. Смысл в том, чтобы делать это заранее, в моменте формирования API.
работать с СУБД с помощью транзакционных операций
Если повезёт, они будут. В некоторых их специально нет. При межсервисном общении тразакций нет по-умолчанию.
Тут хорошо подходит концепция трейсов.
Трейсы относительно обработки ошибок - как PostgreSQL относительно файлов. То есть не везде можно применить (не будешь же трейсы ставить на каждый вызов), несоразмерно сложнее в использовании и обслуживании.
Строка ошибки - идеальный баланс между ясностью (которую Go поощряет на всех уровнях) и простотой.
И если клиенту захочется разобраться - а что же случилось - он скажет нам идентификатор
- Ошибка может произойти на инфре клиента, доступ вряд ли дадут
- Идентификатор может протухнуть
Выплюнули строку из 20 символов и потом думай - что это такое.
Подумать, конечно, придётся. Однако я не вижу что плохого в таких ошибках:
Server failed: initialize server: load config from /etc/myapp/config.json: open /etc/myapp/config.json: no such file or directory
Server failed: handle request for user 123: query user 123: sql: connection is already closed
Исходная версия kaldeon, :
Что значит «вызывающему было хорошо» я не вполне понимаю.
Указать в сообщении что произошло, чтобы вызывающему не пришлось быть чрезмерно многословным в пробрасывании ошибки. Например, os.Open/Read/Write/Close добавляет имя файла. Иногда вернуть частичную информацию (например, при чтении данных). Указать тип (или поведение через интерфейс), чтобы вызывающему было удобно среагировать. Смысл в том, чтобы делать это заранее, в моменте формирования API.
работать с СУБД с помощью транзакционных операций
Если повезёт, они будут. В некоторых их специально нет. При межсервисном общении тразакций нет по-умолчанию.
Тут хорошо подходит концепция трейсов.
Трейсы относительно обработки ошибок - как PostgreSQL относительно файлов. То есть не везде можно применить (не будешь же трейсы ставить на каждый вызов), несоразмерно сложнее в использовании и обслуживании.
Строка ошибки - идеальный баланс между ясностью (которую Go поощряет на всех уровнях) и простотой.
И если клиенту захочется разобраться - а что же случилось - он скажет нам идентификатор
- Ошибка может произойти на инфре клиента, доступ вряд ли дадут
- Идентификатор может протухнуть
Выплюнули строку из 20 символов и потом думай - что это такое.
Подумать, конечно, придётся. Однако я не вижу что плохого в таких ошибках:
Server failed: initialize server: load config from /etc/myapp/config.json: open /etc/myapp/config.json: no such file or directory
Server failed: handle request for user 123: query user 123: sql: connection is already closed