31

What is the list of exceptions that CAN'T be caught in .NET? Or where can I find such a list?

Denis
  • 11,796
  • 16
  • 88
  • 150
  • 12
    `NullReferenceException` can be caught. What made you think it can't be? – John Saunders Sep 12 '11 at 19:15
  • Why do you need such a list? Catch and handle exceptions you can deal with, catch and log exceptions that you can't, and let the OS nuke your process from orbit if something is so catastrophically wrong that the exception can't be caught. – dlev Sep 12 '11 at 19:23
  • or did you mean *shouldn't* instead of *can't*? – jeroenh Sep 12 '11 at 19:23
  • My bad, NullReferenceException was being thrown from an event and I wasn't catching it - didn't realize it was being thrown from an event and no my code - thought it was bypassing my catch statement – Denis Sep 12 '11 at 19:47
  • 1
    I come from Java where there are Runtime exceptions that can't be caught and others that can. Just was wondering if .NET was similar and if so, which exceptions behave like Java's Runtime exceptions. – Denis Sep 12 '11 at 19:48
  • 1
    @Denis: you can definitely catch RuntimeException in java, just like any other Throwable; the special thing about RuntimeException is just that they aren't checked, i.e. you can throw them without declaring them in the method declaration. – Wim Coenen Oct 13 '14 at 13:55

8 Answers8

46

The only exception that cannot be caught directly is (a framework thrown) StackOverflowException. This makes sense, logically, as you don't have the space in the stack to handle the exception at that point. From the docs:

Starting with the .NET Framework version 2.0, a StackOverflowException object cannot be caught by a try-catch block and the corresponding process is terminated by default.

ThreadAbortException can be caught, but will always get re-raised, so has unique behavior. From the docs:

ThreadAbortException is a special exception that can be caught, but it will automatically be raised again at the end of the catch block.

Also note that some AccessViolationException instances are corrupted state exceptions, and may not get handled by default. These can be handled, but require extra handling via attributes. For details, see Handling Corrupted State Exceptions.

Reed Copsey
  • 554,122
  • 78
  • 1,158
  • 1,373
  • 11
    Note that you can suppress the `ThreadAbortException` rethrowing by calling `Thread.ResetAbort()`. (Note: don't do that.) – dlev Sep 12 '11 at 19:24
  • since this is the accepted answer can u add AccessViolationException (http://stackoverflow.com/questions/3469368/how-to-handle-accessviolationexception) – Simon Jul 22 '14 at 20:09
  • @Simon Thouhg you can often catch those with `HandleProcessCorruptedStateExceptions` - so they're not impossible to catch – Reed Copsey Jul 22 '14 at 20:11
  • so u dont think it is worth mentioning in this context? – Simon Jul 22 '14 at 20:12
  • 2
    also "You can catch NullReferenceException without issues." is no longer relevant to the edited question – Simon Jul 22 '14 at 20:13
  • @Simon - this is a good place to post your own answer about AccessViolationException. – H H Jul 22 '14 at 20:39
  • @Simon Put a mention of it in here - – Reed Copsey Jul 22 '14 at 20:42
  • @Reed :Entire Dotnet we have only exception ,we cannot handle it which is "StackOverflowException"? – Sudhir.net May 18 '16 at 05:45
7

NullReferenceException can certainly be caught. Where did you get the idea from?

A try {} catch {} will catch non managed exceptions as well as managed ones (note that there is not exception clause on the catch).

The only one that cannot be caught is StackOverflowException, and TreadAbortException gets rethrown at the end of the catch.

Oded
  • 489,969
  • 99
  • 883
  • 1,009
  • That is not true. Stack overflows will halt execution before you can catch the exception. So there is at lease one. – stephenbayer Sep 12 '11 at 19:19
  • @Oded, there are some edge cases in which that won't happen I believe I think with Enivornment.FailFast and with System.StackOverflow it doesn't – msarchet Sep 12 '11 at 19:21
  • @Oded: It's just one of those interesting tidbits - I with StackOverflow could be caught somehow - it'd make life a lot easier in certain cases :( – Reed Copsey Sep 12 '11 at 19:24
  • @Reed sure you can... Keep a counter in your recursive function (increment every time you enter) if counter >= then throw new LikelyStackOverflowException() - you'll get stacktrace. – Denis Sep 12 '11 at 21:27
  • @Denis: That's not the same as catching a "true" StackOverflowException. Of course you can manage this yourself, but that wasn't what I was suggesting ;) – Reed Copsey Sep 12 '11 at 21:29
4

Try this... (Tested on .NET Core 2.0)

System.Runtime.Serialization.FormatterServices.GetUninitializedObject(typeof(Type).GetType()).ToString()

A System.ExecutionEngineException that ignores all try/catch/finally blocks is thrown, even though it was deprecated saying the runtime NO LONGER THROWS this type of excpetion. Weird, eh?

The reason for this might be typeof(Type).GetType() returns typeof(System.RuntimeType) which is an internal type and a runtime intrinsic. There are validation of arguments by System.Runtime.Serialization.FormatterServices.GetUninitializedObject regarding these types like typeof(string), but the developers probably forgot to check this non-public type. As a result, an invalid System.RuntimeType is returned. When ToString is called, the invalid state causes the runtime to crash.

Happypig375
  • 1,022
  • 1
  • 12
  • 32
  • Unfortunately, `System.Runtime.Serialization.FormatterServices` will be obsoleted in .NET 7 and throw `PlatformNotSupportedException` in .NET 8, so this won't stay long... https://github.com/dotnet/designs/blob/master/accepted/2020/better-obsoletion/binaryformatter-obsoletion.md#entirety-of-binaryformatter-type-obsolete-as-warning – Happypig375 Aug 27 '20 at 07:58
  • Curious. I wonder what will replace `GetUninitializedObject`, since many high performance serializers I've seen depend on it somewhere – to11mtm Nov 08 '20 at 15:49
  • Wow, it's so good, still working on .net core 6 – megapro17 Dec 24 '21 at 17:43
4

ThreadAbortException

Note:

ThreadAbortException is a special exception that can be caught, but it will automatically be raised again at the end of the catch block. When this exception is raised, the runtime executes all the finally blocks before ending the thread.

SwDevMan81
  • 48,814
  • 22
  • 151
  • 184
  • 1
    I wouldn't even count this as it **can** be caught, it's just that it has a side-effect of being re-thrown. Still, +1 for nice find. – Yuck Sep 12 '11 at 19:18
  • 1
    This *can* be caught, and the re-throwing behaviour can be suppressed by calling `Thread.ResetAbort()` – dlev Sep 12 '11 at 19:20
4

Well there are some exceptions that will always be re-thrown even if you catch them. StackOverflowException is the only ones i can think of atm though. possibly ThreadAbortedException.

aL3891
  • 6,205
  • 3
  • 33
  • 37
2

Any exception that you can't reference by type because of accessibility can't be explicitly caught, but can be caught using the base Exception type.

For example, a ContractException in the code contracts framework is purposely made internal to its assembly so that you can't try to catch it explicitly.

Jay
  • 56,361
  • 10
  • 99
  • 123
0

SEHException can't be caught in some cases. It can be thrown by unmanaged code. A great SO thread on this topic appears here: SEHException not caught by Try/Catch

Community
  • 1
  • 1
sevzas
  • 701
  • 2
  • 5
  • 13
0

I don't know why you mentioned NullReferenceExceptions. NullReferenceExceptions are one of the main exceptions I catch. The only one that I can think of off the top of my head is an Out of Memory exception or StackOverflow, because as soon as you are out of memory, execution is halted, and so there is a good chance that the exception can't be caught.

VMAtm
  • 27,943
  • 17
  • 79
  • 125
stephenbayer
  • 12,373
  • 15
  • 63
  • 98