Винятки або коди помилок

12

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

Що б ви хотіли в обробці на стороні клієнта: отримання коду помилки чи обробку виключення ServerFault, що містить причину помилки?
1) Чому ми думаємо про виняток: тому що це зробить кодовий бік сервера набагато більш рівномірним
2) Чому ми думаємо про коди помилок: Тому що, на нашу думку, це має більше сенсу з точки зору клієнта.

Якщо 2) дійсно вірно, ми, ймовірно, хотіли б шукати коди помилок, ніж винятки? Це так?

Також чи змінилася б відповідь, якби ми говорили з керованими клієнтами замість рідних клієнтів?

programming-practices exceptions error-handling

— Аміт Вадхва
джерело

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

— Аміт Вадхва

Це може Допомога- www.codeproject.com/KB/cpp/cppexceptionsproetcontra.aspx

— Gulshan

8

SOAP має поняття несправностей , ви можете перетворити виняток у помилку на стороні сервера, а на клієнтському проксі помилка може знову бути перетворена назад у виняток. Це чудово працює в WCF та Java стеці метро, не може коментувати рідних клієнтів C ++.

Що стосується найкращої практики SOA, визначте одну загальну помилку та декілька конкретних несправностей, лише якщо клієнту потрібно по-різному поправити певний тип помилок. Ніколи не надсилайте сліду стека винятків клієнтові при виробництві. Це тому, що теоретично трасування сервера не має значення для клієнта, а також з міркувань безпеки. Реєструйте повну помилку та стек-трек на сервері та надішліть унікальну посилання на журнал помилки. У WCF я використовую блок обробки винятків Microsoft з Enterprise Library, щоб генерувати настанови, а також конвертувати виняток у помилку SOAP.

Перегляньте вказівки в Microsoft Patterns and Practices .

— софтведа
джерело

Спасибі це звучить добре. Чи можете ви надати мені більш конкретне посилання на сторінці там.

— Amit Wadhwa

А також щодо помилок на рівні бізнесу, таких як UserNotFound тощо. Чи слід також їх обробляти як винятки

— Amit Wadhwa

У минулих проектах ми ніколи не використовували Винятки в коді або Несправності в SOAP для передачі законних / очікуваних режимів відмови. Ми використовували коди помилок і залишали їх клієнтові, щоб вирішити, що з ними робити. Користувача не знайдено - це насправді помилка / виняток, це, мабуть, має бути код статусу.

— MrLane

4

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

Можливість того, щоб клієнт надавав сліду стека у звіті про помилку для розробника, був дуже корисним (на відміну від отримання приблизної часової позначки, а потім доведеться шукати його у своїх журналах, якщо у вас це трапиться).

Тож, розглянуті з точки зору розробників, використовуйте Винятки.

1

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

— Аміт Вадва

2

@ Дозвольте, повірте мені з цього приводу: Якщо ви потрапили в ситуацію, що дає стек стежок у виробництві, ви ХОЧЕТЕ слід стека!

1

Яка перевага відстеження стека на стороні клієнта. Ми обов'язково запишемо всі винятки на стороні сервера, перш ніж передавати його клієнту.

— Amit Wadhwa

А також щодо помилок на рівні бізнесу, таких як 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: Якщо це веб-сервіс, а не веб-сайт , клієнт повинен бути достатньо професійним, щоб надіслати його електронною поштою як повідомлення про помилку.

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