Исключения или коды ошибок

12

Мы создаем веб-сервис (SOAP, .Net), который будет взаимодействовать (главным образом) с собственными клиентами (windows, C ++), и нам интересно, как лучше всего сообщить клиенту об ошибках (например, SomethingBadHappened, например, служба входа недоступна) или что-то вроде пользователя не найден), и он не смог решить, выдать ли клиенту исключение или использовать какую-либо модель кода ошибки для выполнения вышеупомянутого.

Что бы вы предпочли при обработке на стороне клиента: получение кода ошибки или обработка исключения ServerFault, которое содержит причину ошибки?
1) Почему мы думаем об исключении: потому что это сделает код на стороне сервера более единообразным
2) Почему мы думаем о кодах ошибок: потому что мы думаем, что это имеет больше смысла с точки зрения стороны клиента.

Если 2) действительно верно, мы бы хотели использовать коды ошибок, а не исключения? Это тот случай, здесь?

Кроме того, изменится ли ответ, если мы будем говорить с управляемыми клиентами вместо собственных клиентов?

programming-practices exceptions error-handling

— Амит Вадхва
источник

Просто для пояснения: а) я ищу здесь лучшие практики и опыт со стороны клиента (так как клиент намного сложнее, и мы бы предпочли обрабатывать вещи на стороне сервера, если бы мы могли упростить клиентский код) б) Клиент содержит много устаревшего кода, и мы можем или не можем использовать исключения C ++.

— Амит Вадхва

Это может помочь

— Гюльшан

8

У SOAP есть концепция сбоев : вы можете преобразовать исключение в сбой на стороне сервера, а на клиентском прокси-сервере сбой снова может быть преобразован обратно в исключение. Это замечательно работает в WCF и Java-стеке, не может комментировать нативные клиенты C ++.

Что касается передовой практики SOA, определите одну общую ошибку и несколько конкретных ошибок только в том случае, если клиенту необходимо обработать определенный тип ошибки по-другому. Никогда не отправляйте трассировку стека исключений клиенту в производственном развертывании. Это связано с тем, что теоретически трассировка сервера не имеет значения для клиента, а также по соображениям безопасности. Зарегистрируйте полную ошибку и трассировку стека на сервере и отправьте уникальную ссылку на журнал в сбое. В WCF я использую блок обработки исключений Microsoft из Enterprise Library для генерации guid, а также для преобразования исключения в ошибку SOAP.

Проверьте руководство в Microsoft Patterns and Practices .

— softveda
источник

Спасибо, это звучит хорошо. Можете ли вы дать мне более конкретную ссылку там на странице там.

— Амит Вадхва

Кроме того, что касается ошибок бизнес-уровня, таких как UserNotFound и т. Д., Следует ли их обрабатывать как исключения

— Amit Wadhwa

В прошлых проектах мы никогда не использовали исключения в коде или ошибки в SOAP для передачи допустимых / ожидаемых способов отказа. Мы использовали коды ошибок и оставили их клиенту, чтобы решить, что с ними делать. Пользователь не найден, на самом деле это не ошибка / исключение, вероятно, это должен быть код состояния.

— MrLane

4

Недавно я сделал веб-сервис с библиотеками Java 6, который может сообщить об исключительной ситуации вызывающей стороне (я не изучал, как это происходит автоматически).

Возможность заставить клиента предоставлять трассировку стека в отчете об ошибках для разработчика была очень полезной (в отличие от получения приблизительной отметки времени, а затем ее поиска в журналах, если вы ее регистрировали).

Итак, с точки зрения разработчиков, используйте исключения.

1

Я согласен, что это может быть полезно в собачьей еде и бета-версии, но действительно ли вы хотите извергать следы стека в журналах событий или файлах журналов в реальном мире (и, конечно, раскрывать больше подробностей об услуге, чем вам нужно / нужно в процессе )

— Амит Вадхва

2

@Amit, поверьте мне: если вы попадаете в ситуацию, когда в процессе возникает трассировка стека, вы ХОТИТЕ трассировку стека!

1

В чем преимущество трассировки стека на стороне клиента? Мы обязательно запишем все исключения на стороне сервера, прежде чем передать их клиенту.

— Амит Вадхва

Кроме того, что касается ошибок бизнес-уровня, таких как UserNotFound и т. Д., Следует ли их обрабатывать как исключения

— Amit Wadhwa

-2

Если это веб-служба, вы не можете заставить сервер выдать исключение, которое будет перехвачено клиентом. В интерфейсе ваш сервер в основном должен возвращать некоторый код ошибки, даже если это строка, которая говорит An exception occurred. Type %s, message %s, stack trace %s.

Что касается клиентской стороны, вы можете попросить код чтения ответа проверить ответ, чтобы увидеть, содержит ли он ошибку, и вызвать исключение на стороне клиента. Это очень хороший способ сделать это, по крайней мере, на языках с хорошей обработкой исключений. C ++, однако, не имеет хорошей обработки исключений, и это хорошая идея, чтобы держаться как можно дальше от исключений C ++. Если вы не можете использовать лучший язык, просто придерживайтесь кодов ошибок.

— Мейсон Уилер
источник

Я предполагаю, что необработанное исключение пойдет как ServerFault к клиенту

— Amit Wadhwa

3

В исключениях C ++ или C ++ нет ничего плохого. Существует множество причин использовать язык, отличный от C ++, для определенных проектов, но обработка исключений не является одной из них.

— KeithB

Мало того, что это противоречит рекомендациям по безопасности: что именно должен делать клиент с трассировкой стека вашего сервера? Распечатать и отправить вам? Отправить по электронной почте? Использовать для смазочной бумаги?

— JensG

@JensG: Если это веб-сервис, а не веб-сайт , клиент должен быть достаточно профессиональным, чтобы отправить его вам в виде сообщения об ошибке.

— Мейсон Уилер