Как поймать ВСЕ исключения/катастрофические отказы в приложении.NET [дубликат]
В Java все переменные, которые вы объявляете, на самом деле являются «ссылками» на объекты (или примитивы), а не самими объектами.
При попытке выполнить один метод объекта , ссылка просит живой объект выполнить этот метод. Но если ссылка ссылается на NULL (ничего, нуль, void, nada), то нет способа, которым метод будет выполнен. Тогда runtime сообщит вам об этом, выбросив исключение NullPointerException.
Ваша ссылка «указывает» на нуль, таким образом, «Null -> Pointer».
Объект живет в памяти виртуальной машины пространство и единственный способ доступа к нему - использовать ссылки this. Возьмем этот пример:
public class Some {
private int id;
public int getId(){
return this.id;
}
public setId( int newId ) {
this.id = newId;
}
}
И в другом месте вашего кода:
Some reference = new Some(); // Point to a new object of type Some()
Some otherReference = null; // Initiallly this points to NULL
reference.setId( 1 ); // Execute setId method, now private var id is 1
System.out.println( reference.getId() ); // Prints 1 to the console
otherReference = reference // Now they both point to the only object.
reference = null; // "reference" now point to null.
// But "otherReference" still point to the "real" object so this print 1 too...
System.out.println( otherReference.getId() );
// Guess what will happen
System.out.println( reference.getId() ); // :S Throws NullPointerException because "reference" is pointing to NULL remember...
Это важно знать - когда больше нет ссылок на объект (в пример выше, когда reference и otherReference оба указывают на null), тогда объект «недоступен». Мы не можем работать с ним, поэтому этот объект готов к сбору мусора, и в какой-то момент VM освободит память, используемую этим объектом, и выделит другую.
11 ответов
Вопреки тому, что отправили некоторые другие, нет ничего неправильно ловящего все исключения. Важная вещь состоит в том, чтобы обработать их всех соответственно. Если у Вас есть переполнение стека или из условия памяти, приложение должно закрыться для них. Кроме того, имейте в виду, что условия OOM могут препятствовать тому, чтобы Ваш обработчик исключений работал правильно. Например, если Ваш обработчик исключений отображает диалоговое окно с сообщением об исключении, если Вы вне памяти, не может быть достаточного количества, которое осталось для диалогового дисплея. Лучше всего зарегистрировать его и закрыться сразу.
, Поскольку другие упомянули, существуют события UnhandledException и ThreadException, которые можно обработать к исключениям набора, которые могли бы иначе быть пропущены. Тогда просто бросьте обработчик исключений вокруг своего основного цикла (принимающий приложение winforms).
кроме того, необходимо знать, что OutOfMemoryExceptions не всегда бросаются для из условий памяти. Условие OOM может инициировать все виды исключений в Вашем коде, или в платформе, которые не обязательно имеют какое-либо отношение к тому, что реальная причина вне памяти. Я часто видел InvalidOperationException или ArgumentException, когда первопричина на самом деле вне памяти.
Можно добавить обработчик событий к AppDomain. Событие UnhandledException, и это назовут, когда исключение будет выдано и не поймано.
Эта статья в codeproject нашим хостом Jeff Atwood - то, в чем Вы нуждаетесь. Включает код для ловли необработанных исключений и лучших методов для проявления информации о катастрофическом отказе пользователю.
класс Global.asax является Вашей последней линией обороны. Посмотрите на:
protected void Application_Error(Object sender, EventArgs e)
метод
Знайте, что некоторое исключение опасно для выгоды - или главным образом неуловимо,
- OutOfMemoryException: что-либо, что Вы делаете в обработчике выгод, могло бы выделить память (в управляемой или неуправляемой стороне CLR) и таким образом инициировать другой OOM
- StackOverflowException: завися, обнаружил ли CLR его достаточно рано, Вы могли бы быть уведомлены. Худший вариант развития событий, это просто уничтожает процесс.
Можно использовать AppDomain. CurrentDomain. UnhandledException для получения события.
Хотя ловя весь исключениями без плана правильно обработать их является, конечно, плохая практика, я думаю, что приложение должно перестать работать некоторым корректным способом. Катастрофический отказ не должен пугать пользователя до смерти, и по крайней мере он должен отобразить описание ошибки, некоторая информация, чтобы сообщить материалу технической поддержки, и идеально кнопке закрывать приложение и перезапускать его. В идеальном мире приложение должно быть в состоянии вывести на диске пользовательские данные, и затем попытаться восстановить его (но я вижу, что это спрашивает слишком много).
Так или иначе, я обычно использую:
AppDomain.CurrentDomain.UnhandledException
Можно также пойти с Приложением. Событие ThreadException.
, Как только я разрабатывал приложение.NET, работающее в COM, основывал приложение; это событие было очень полезным как AppDomain. CurrentDomain. UnhandledException не работал в этом случае.
Я думаю, что Вы даже не должны скорее ловить все Исключение, но лучше позволять им быть показанными пользователю. Причина этого состоит в том, что необходимо только поймать Исключения, которые можно на самом деле обработать. Если Вы сталкиваетесь с некоторым Исключением, которое заставляет программу останавливаться, но все еще поймать его, это могло бы вызвать намного более серьезные проблемы. Также читайте FAQ: Почему FxCop предостерегает от выгоды (Исключение)? .
Знайте, что ловля этих необработанных исключений может изменить требования к защите Вашего приложения. Ваше приложение может прекратить работать правильно под определенными контекстами (когда выполнено от сетевого ресурса, и т.д.). Обязательно протестируйте полностью.
не повреждает использовать оба AppDomain. CurrentDomain. Приложение UnhandledException. ThreadException
, но имеет в виду, что исключения на вторичных потоках не пойманы этими обработчиками; используйте SafeThread для вторичных потоков в случае необходимости