Что делать с пойманным исключением

Question

Когда служба WCF отключена, я собираюсь это исключение.

public List<ProjektyEntity> GetProjekty() 
    { 
     try 
     { 
     return this.channel.GetProjekty(); 
     } 
     catch (EndpointNotFoundException exception) 
     { 
      //what to do at this point ? 
     } 
    } 

Но я не знаю, что делать в улове или блок может возвращать только объект типа List<ProjektyEntity> Я хотел бы написать сообщение пользователя, что-то вроде «Служба отключена «Мой уровень представления - ASP.NET MVC. Существует ли какая-либо стратегия для подобных ситуаций?

Answer 1

Существует простое правило: если вы не знаете, как обрабатывать исключение, не поймите его.

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

Ловля исключения и реорганизация его как throw e; также плохо, потому что вы теряете исходный стек. Повторное использование с использованием throw; в порядке, если у вас есть специальная очистка, вам нужно сделать это только в случае ошибки. Обычно это не так. Если у вас есть очистка, которая должна быть выполнена независимо от того, была или нет ошибка, она принадлежит в предложении finally.

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

Есть несколько раз, когда вы можете поймать исключение, чтобы добавить дополнительную информацию (например, для лесозаготовки), в этом случае вы должны убедиться, что вы используете InnerException, чтобы избежать потерь исходной информации:

try 
{ 
    foo(bar); 
} 
catch (Exception e) 
{ 
    throw new FooException("Foo failed for " + bar.ToString(), e); 
} 

, но в целом лучше не делать этого, если у вас нет веской причины. Это не позволяет вашим пользователям перехватывать определенный тип исключения - они поймают ваше исключение, а затем им нужно будет включить тип InnerException. Не весело. Просто позвольте вызывающему абоненту увидеть исходное исключение.

Answer 2

Мне кажется, что вы не должны улавливать это исключение на этом слое; вы должны позволить исключению распространяться до уровня контроллера, а слой контроллера отображает сообщение.

Answer 3

Здесь я могу посмотреть несколько вариантов. Определение того, что подходит, вероятно, зависит от приложения.

• Отображается сообщение об ошибке и возвращает null. Чистый и простой, но негибкий. Возможно, это не то, что вы хотите в каждом случае, где используется эта функция.
• Не поймайте его, позвольте собеседнику уловить это исключение. Это может быть проще, чтобы определить соответствующий ответ от вызывающей функции (то есть. Отобразить сообщение/Повторите попытку через несколько секунд/и т.д.)
• Поймайте его и бросить новый ServiceNotAvailableException Чуть более сложный, чем второй вариант, но будет сделать код более понятным.
• Просто верните null. Вероятно, наименее желательный подход, если эта служба не является обычной и не имеет большого значения.

Answer 4

Создать объект исключения с достаточно подробной отладки и бросить его вызова метода

Answer 5

Исключение не должно быть перехвачены и обработаны в этом контексте. Его нужно обрабатывать на гораздо более высоком уровне, имея доступ к любой консоли в целом.

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

Answer 6

Есть несколько подходов:

1) Не поймать исключение, и пусть вызывающий (граничный слой пользователя) обрабатывать его

2) Поймать исключение, так что вы можете делать все, что нужно делать, а затем вновь бросить его

catch (EndpointNotFoundException exception) 
{ 
    CleanUpMyOwnState(); 
    throw;     // Pass the exception on the to the caller to handle 
} 

3) Преобразование исключение в другой тип (чтобы сделать его проще в обращении в вызывающем):

catch (EndpointNotFoundException exception) 
{ 
    CleanUpMyOwnState(); 
    throw new InvalidOperationException("Endpoint was not found", exception); 
} 

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

5) Устраните исключение и сообщите об ошибке пользователю. Вероятно, это плохая идея - вы должны хранить отчеты об ошибках в своем пользовательском интерфейсе.

Answer 7

public List<ProjektyEntity> GetProjekty() 
    { 
     try 
     { 
     return this.channel.GetProjekty(); 
     } 
     catch (EndpointNotFoundException exception) 
     { 
      'Write here Some Clean Up Codes 
      ' Log it somewhere on your server so that you can fix the error 

     } 
    }