Лучшие практики - создание исключений из веб-службы

Question

У нас есть веб-сервис ASMX, который мы вызываем из нашего приложения ASP.NET, используя ajax (jQuery).

Типичным примером наших веб-методов будет что-то вроде:

[WebMethod]
public void DoSomething(BusinessObject myParameter)
{

    try
    {
       BL.DoSomethingWithParam(myParameter);
    }
    catch(Exception ex)
    { 
        //logic to log the actual exception goes here
        //and then we throw a more user-friendly error as so:
        throw new Exception("Unable to perform action such an such");
    }
}

На стороне клиента у нас будет что-то вроде этого:

$.ajax({
   type: "POST",
   url: "WebService.asmx/DoSomething",
   data: "{}",
   contentType: "application/json; charset=utf-8",
   dataType: "json",
   success: function(result) {
      //do something with result.d
    },
   error: function(xhr, ajaxOptions, thrownError){ 
      alert($.parseJSON(xhr.Response.Text).Message);
   }
});

Естьнесколько проблем с вышеуказанным подходом, которые я хочу исправить:

1. Когда мы тестируем наше приложение локально на наших компьютерах, Internet Explorer отображает фактическое сообщение об ошибке, которое мы бросаем в новую строку исключения в нашем веб-методе.(В случае примера, приведенного в коде: «Невозможно выполнить действие, такое-то и то-то») НО , когда мы внедряемся в среду этапа и проводим удаленное тестирование;он больше не отображает выдаваемую нами ошибку, а скорее так: "There has been an error processing your request."
2. В Firefox (мы не тестировали больше браузеров) он вообще ничего не отображает, но Firebug показывает ошибку HTTP 500, являющуюсявыброшены.

В заключение мы не обращаемся с этим должным образом, поэтому мои вопросы:

1. Каков наилучший способ сообщить об этих ошибках на стороне клиента и иметь согласованное поведение среди всехбраузеры, как при локальном, так и удаленном тестировании?
2. Почему IE не работает так же, как Firefox?Конечно, удаленное тестирование в IE тоже не работает, не показывая реальное сообщение об ошибке и не заменяя его на There has been an error processing your request, но почему Firefox не делает то же самое?
3. Учитывая тот факт, что этот веб-сервис также будет использоваться другими веб-приложениями Java в компании, каков наилучший способ обеспечения взаимодействия с этими приложениями?Как мы можем по-прежнему генерировать эти исключения в наших веб-методах, и чтобы приложение Java могло их перехватывать и обрабатывать соответствующим образом?

Одна из альтернатив, которую мы реализовали - пока, мы все еще на стадии разработки - это просто возвращать строку из наших веб-методов при возникновении ошибки, но это действительно уродливый хакерский / неэффективный способ сделатьэтот.

Примечание : Не спрашивайте меня, откуда приходит сообщение «Произошла ошибка при обработке вашего запроса».У меня нет ни малейшего представления.В нашем коде нет ничего, что могло бы вернуть это сообщение.

Answer 1

Я не знаю, что «правильный» путь еще не появился из-за того, что использование веб-сервисов меняется так быстро, и, в конечном счете, любой клиент, созданный для использования сервиса, способен обрабатывать любой метод твой выбор. Я не сомневаюсь, что в конечном итоге одна из них будет изобретена, но пока это зависит от вас.

При этом старайтесь избегать некоторых из наиболее распространенных ошибок, которые я видел в прошлом.

1. Недостаток согласованности: если в вашем веб-сервисе есть несколько методов, разработайте способ, которым они могут сообщать об ошибках одинаковым образом, чтобы ваши методы было проще использовать. Лично я предпочитаю идти по стопам стеков протоколов и использовать какой-то непротиворечивый заголовок. Создайте полученные в результате сообщения с общим заголовком, чтобы одна и та же логика могла использоваться во всем коде клиента, чтобы определить, был ли вызов метода успешным.
2. Нет поддержки нескольких сообщений об ошибках: иногда возникало несколько сбоев. Ослепление клиента вторичной ошибкой может вызвать неудобства и замедлить попытки отладки.
3. Отсутствие идентификации для сообщений об ошибках: если ошибка является результатом того, что конкретное поле является недействительным, разрешите клиенту программно определить, какое поле является виновником, на основе предоставленной вами информации.

Подход, с которого я обычно начинаю в эти дни, выглядит примерно так:

{
    Success: bool,
    Errors[]: {
        Id: string,
        Source: string,
        Message: string
    },
    Message: { *Method specific structure* }
}