Это в порядке для выдавания исключения назад клиенту от моего сервиса?
Я пишу основанный на Java сервис с WSDL для клиента .NET для потребления, и я думал что, когда я получаю недопустимое значение от клиента, что я выдал бы исключение, которое мой клиент мог тогда поймать и отобразить в окне сообщения или чем-то пользователю (клиент является настольным приложением).
Я задавался вопросом, будет ли нормально использовать этот подход или если существует лучший способ сделать его.
5 ответов
Я бы сказал «нет». Сообщения об ошибках и т. Д., Но я бы не стал сериализовать исключение. Вы понятия не имеете, кто является клиентом или на каком языке он написан.
Служба должна обрабатывать исключение: перехватывать его, регистрировать и создавать разумные сообщения об ошибках и коды состояния. На мой взгляд, здесь не место для исключений.
И когда я говорю «разумные сообщения об ошибках», я не имею в виду ничего похожего на трассировку стека. Скорее всего, это будут бизнес-клиенты, которым не следует читать такие вещи. Здесь билетом является бизнес-значимое сообщение, а не трассировка стека.
$ perl -0pe 's/\n,/,/g' < test.dat 92831,499,000,0644321 79217,999,000,5417178,PK91622,PK90755
Перевод: Прочитайте массово без разделения строк, замените каждую запятую после новой строки на запятую.
Здесь самый короткий код!
-121--3653449-Я думаю, что это потому, что наличие заголовка в каталоге не обязательно означает, что вы хотите, чтобы этот каталог искал любые другие заголовки. Этот конкретный заголовок может быть включен путем указания пути к заголовку, или он может быть неявно найден, поскольку находится в том же каталоге, что и файл, включающий его.
Все, что я сказал (и это просто домыслы), я думаю, что вы хотите это разумный запрос (это то, что вызывало у меня крошечное разочарование раньше) - по крайней мере, как вариант или путем запроса.
-121--4268413-Первое, что нужно решить, - это предотвратить возникновение исключений путем проверки данных до того, как ими манипулируют. IE
string func (строковый кат)
if (cat = = null | | cat.length = = 0) {
//установите значение ErrorLabelText как «bad data»
возврат;
}
//else code
Это, как говорят, приводит только к исключениям в исключительных случаях.
.NET обычно имеет дело с исключениями FaultExceptions (обернутыми ошибками SOAP) в WCF. Я бы предположил, что если вы выбросите правильный SOAP Fault, WCF превратит это в FaultException к тому времени, когда клиент получит ответ, чтобы они могли попытаться поймать оператор FaultException. Это по-прежнему позволит другим клиентам, не являющимся .NET, использовать службу без нарушения стандартов.
В любом случае, это просто идея ...
Что вам, вероятно, следует сделать, так это использовать ошибки SOAP, поскольку они должны поддерживаться для любых клиентов. Не забудьте также установить дополнительные описательные поля.
Концептуально это нормально, но я не думаю, что вы можете буквально передать исключение Java через HTTP обратно клиенту .NET.
Вы можете использовать HTTP 500, чтобы сигнализировать об ошибке сервера; вы также должны иметь возможность прикрепить к ответу содержательное сообщение, которое поможет разработчикам .NET понять, как лучше использовать ваш сервис. Это может включать или не включать сериализованную трассировку стека Java.