Develop Reference

How do I find the exception type of an exception that gets thrown in C#?

I am using a library that doesn't seem to document the exceptions. This library is used to communicate with a product the company makes. I want to be able to differentiate between the exceptions that get thrown but I don't know the names of the exceptions (for example between a communication timeout or under-voltage condition).
All of their examples only use catch(Exception ex). How can can I find what I need to use to catch the individual errors? When I do ex.toString() I get something like this:
System.Exception: Timeout
at CMLCOMLib.EcatObj.Initialize()
at copley_cmo_test.MainWindow.btnConnect_Click(Object sender, RoutedEventArgs e)
in c:\Users\adam.siembida\Desktop\copley_cmo_test\copley_cmo_test\MainWindow.xaml.cs:line 41

This:
System.Exception: Timeout
shows that they're just throwing a bare System.Exception, e.g.
if (weHaveNoApiDesignSkills)
{
throw new Exception("Timeout");
}
It's possible that there are some exceptions which are better designed, but the one you've shown isn't promising :(
Unfortunately unless you start using the message in the exception to differentiate between them (which is almost always a bad idea) you're stuck. It may be worth asking the authors of the library to see if they can improve matters for a future release.

Catch it with a catch-all construct such as catch(Exception ex), then examine the Type returned by ex.GetType(). If it's equal to typeof(Exception), it means that they aren't throwing anything more specific than Exception.

By the way, if you're stopped when the exception has been caught (ie, in a catch block), if you enter $exception in the watch window, you will see the entire exception.

When the API in library which you are using is not documented properly , you should catch the base exception and log it not only by the message instead whole exception by converting the exception to string . Eg.
try
{
//api call which throws exception.
}
catch(Exception ex)
{
//log ex.ToString();
}

use a decompiler for example:
http://www.jetbrains.com/decompiler/
in .net there's no explicit exception declaration like in java so as i see it it's the only way.

Is an empty catch the same as "catch Exception" in a try-catch statement?

try {
}
catch (Exception) {
}
can I just write
try {
}
catch {
}
Is this ok in C# .NET 3.5? The code looks nicer, but I don't know if it's the same.

They are not the same.
catch (Exception) { } will catch managed exceptions only; catch { } will catch non-CLS exceptions as well: http://msdn.microsoft.com/en-gb/bb264489.aspx
An unhandled non-CLS compliant
exception becomes a security issue
when previously allowed permissions
are removed in the catch block.
Because non-CLS compliant exceptions
are not caught, a malicious method
that throws a non-CLS compliant
exception could run with elevated
permissions.
Edit: Turns out .NET 2.0+ wraps the values -- so they are the same. That's a bit of a relief!

Yes, the advantage of the first form is that you can name the exception variable and then use the object to log the exception details to file, etc...
try {
}
catch (Exception ex) {
// Log exception message here...
}
Also, it is generally a bad practice to catch the generic Exception class if you can instead catch specific exceptions (such as an IOException) using the first form.

Edit: As of C# 2.0, non-CLS-compliant exceptions can be caught in both ways.
So, yes. They are identical. A parameter-less catch clause without a Type declaration catches all Exceptions.
In the CLR 2.0, MS introduced RuntimeWrappedException, which is a CLS-compliant exception type, to encapsulate non-CLS-compliant exceptions. The C# compiler still doesn't allow you to throw them, but it can catch them with the catch (Exception) { } syntax.
This is why the C# compiler will issue warning CS1058 if you use both clauses at the same time on CLR 2.0 or later.
Thus, they are in fact identical.

Its the same, but if you put an e after Exception in your first example then you know what exception was thrown...
edit: you should never catch exception, how do you know how to handle it properly?

They are different as noted:
An unhandled non-CLS compliant exception becomes a security issue when previously allowed permissions are removed in the catch block. Because non-CLS compliant exceptions are not caught, a malicious method that throws a non-CLS compliant exception could run with elevated permissions.
You can see the difference in the IL generated:
//no (Exception)
.try L_0001 to L_0005 catch object handler L_0005 to L_000a
//with (Exception)
.try L_0001 to L_0005 catch [mscorlib]System.Exception handler L_0005 to L_000a

I guess unless you want to use the Exception in some sort, the second one is perfectly fine, though in order to use the exception in the first one, you need to declare a variable like this:
try {
}
catch (Exception e) {
//do something with e
}

Both of your examples appear like you're not doing anything with the exception data. This is generally not a good practice. But both are exactly the same since all exceptions classes are derived from System.Exception.
You should consider doing some type of logging then possibly rethrow the original exception or wrap it in a more specialized exception that your application can understand.
try
{
// Some code here
}
catch(Exception ex)
{
// Do some logging
throw;
}
OR
try
{
// Some code here
}
catch(Exception ex)
{
// Do some logging
// wrap your exception in some custom exception
throw new CustomException("Some custom error message, ex);
}
You should typically only catch exceptions that your code could handle, otherwise it should bubble up and it should eventually be caught by a global exception handler assuming you have one.

Parameter less constructor will cause handling of exception types coming from some other languages, exception which are not inherited from c# SYSTEM.EXCEPTION class.

C# try {} catch {}

hi and thanks for reading. im a newbie in programming and C# and sockets programming. in my code i try and catch problems to provide fault tolarence in my app. the following:
catch (ArgumentNullException e)
{
OnNetworkEvents eventArgs = new OnNetworkEvents("Network Unavailable", e.Message);
OnUpdateNetworkStatusMessage(this, eventArgs);
}
catch (EncoderFallbackException e)
{
OnNetworkEvents eventArgs = new OnNetworkEvents("Network Unavailable", e.Message);
OnUpdateNetworkStatusMessage(this, eventArgs);
}
catch (SocketException e)
{
OnNetworkEvents eventArgs = new OnNetworkEvents("Network Unavailable", e.Message);
OnUpdateNetworkStatusMessage(this, eventArgs);
}
catch (ArgumentOutOfRangeException e)
{
OnNetworkEvents eventArgs = new OnNetworkEvents("Network Unavailable", e.Message);
OnUpdateNetworkStatusMessage(this, eventArgs);
}
catch (ObjectDisposedException e)
{
OnNetworkEvents eventArgs = new OnNetworkEvents("Network Unavailable", e.Message);
OnUpdateNetworkStatusMessage(this, eventArgs);
}
i was just wondering if i can replace this repetitive code with one single:
catch (Exception e) { handle here}
would this work?
thanks again.

No, never catch System.Exception. I feel like a broken record today, but I really can't stress this enough. You cannot handle an OutOfMemoryException or AccessViolationException, so don't catch it!
As for the example code, I have strong doubts that an ArgumentNullException or ArgumentOutOfRange exception would correspond to a network error. If it does, it likely means that the component that really should be catching this exception, isn't.
"Fault tolerance" does not mean "eat every exception so the app doesn't crash" - it means actually knowing the things that can go wrong and handling them correctly.

As a general guideline, don't catch System.Exception. It's a bad idea and a bad code smell indicative of a failure to grasp the purpose of exceptions. I believe it's the result of a dev's belief that exceptions are the error instead of the code that triggered the exception.
I see this failure in production code all the time, and it invariably masks real errors as valid and useful exceptions are caught and swallowed, leaving the application in a bad state. This makes it much trickier to track down the root cause of a failure.
Catching exceptions using the method you've used here is more-or-less the right way to do it. There are a few things you might want to consider improving on, though:
Don't generally treat an ArgumentNullExceptionor ArgumentOutOfRangeException as a runtime network failure (unless it really is). Rather, it should be considered a logic error that causes your program to fail as quickly as possible (so that you can check it out with a debugger as close as possible to the point of failure). This frequently means not catching any ArgumentException at all.
Consider examining the exception hierarchy to find an appropriate base exception that covers the exceptions you're trying to report. E.g., (I haven't looked it up), suppose that three of your exceptions all derived from SocketException. You might save some typing by catching a SocketException instead of the three separate exception. Only do this if you're reporting all socket exceptions, however. (This is basically a more disciplined version of your original attempt to just catch Exception)
Because both lines in every exception handler are identical, you may create a function to do those two lines of work in a single line in the handler. Typical don't-repeat-yourself refactoring. If you want to change the way you report your exception, think about how much easier it would be to change a single function than all those individual handlers.
Just about any significant I/O (network and file come to mind) is going to entail a pretty significant chain of exception handlers just because there's so much that can go wrong. Seeing a lot of error reporting around I/O that may fail isn't an anti-pattern, but it may be a good code smell. Like pine-fresh scent or freshly baked bread. :)

That will certainly catch all exceptions, but that can be poor practice. There are some exceptions that will be hidden or misrepresented that will make testing and debugging your application much more difficult.

You could but you would lose granularity and the ability to handle each issue individually, which isn't the best practice. Usually you would handle different types of exceptions first, just as you have, then if you need to do something with any unhandled exceptions you could add the Exception at the end. Re-throw it once you're done to preserve the stack-trace and let it bubble up.
Keep what you have an add a base case at the end:
catch (ArgumentNullException e) { ... }
catch (EncoderFallbackException e) { ... }
catch (SocketException e) { ... }
catch (ArgumentOutOfRangeException e) { ... }
catch (ObjectDisposedException e) { ... }
catch (Exception e)
{
// not handled by above exceptions, do something if needed
throw; // after doing what you need, re-throw it
}

As all previous comments suggest, you should catch all the "known" exceptions with exception specific catch block and other unknown, or more appropriately, all "unmatched" exceptions with catch (Exception ex) { ... } or just catch { ... }
However, as specified in your code, you are handling all kind of exceptions in same way. So in this particular case, the output (what you are calling Fault Tolerance) will be the same, but the performance will improve (since the runtime need not compare exception type with given list of types).
Moral of the story : Use single common try-catch in this particular case. But in general, avoid such habit.

It would work, but it would also catch "null reference" exceptions and any other random exception that got thrown.

Yes it would work, but it would not do the same, since all exceptions and not only the specific ones would be catched.
This is usually not what you want, as the general rule is to catch only exceptions which you know how to handle. There are some situations where you need such a catch-all to redirect the exception (like accross thread boundaries or in async calls) or do some cleanup work if something - anything - goes wrong (but then you usually re-throw the exception after doing your work).

It would catch all exceptions which inherit from Exception class. If they all are handled in the same way you can do it but you shouldn't as you can't handle all Exceptions inherited from Exception in the same way.

I actually just read a blog post on this very topic this morning.
You could do something like mentioned in the comments of the post:
catch(Exception e){
if( e is ArgumentNullException
|| e is EncoderFallbackException
|| e is ...whatever
){
OnNetworkEvents eventArgs = new OnNetworkEvents("Network Unavailable", e.Message);
OnUpdateNetworkStatusMessage(this, eventArgs);
} else { throw; }
}

While you can do that , I'd consider it poor practice and not how you'd want to be structuring your code.
Depending on the exception you may want to do something different. An invalid IP is a different issue than a hardware error and so on. Additionally some errors you might want to notify back to the UI via a delegate or log somewhere using log4net.
But that's just me and I'm far from an expert - so take it for what it's worth

IMO:
Catching Exception would be pretty similar to having methods with parameters that are never more specific of a class than Object; Sure you can do it but is it really the best decision 9 out of 10 times?
What you should consider doing to simplify your code some is Catch exceptions at the highest definition that is relevant.
For instance, in java I would
try{...}
catch( IOException e ) {...}
to catch all IO related exceptions.
There are too many things that can throw too many different types of exceptions, you typically should avoid using the catch-all that is Exception.

Thoughts on try-catch blocks

What are your thoughts on code that looks like this:
public void doSomething()
{
try
{
// actual code goes here
}
catch (Exception ex)
{
throw;
}
}
The problem I see is the actual error is not handled, just throwing the exception in a different place. I find it more difficult to debug because i don't get a line number where the actual problem is.
So my question is why would this be good?
---- EDIT ----
From the answers it looks like most people are saying it's pointless to do this with no custom or specific exceptions being caught. That's what i wanted comments on, when no specific exception is being caught. I can see the point of actually doing something with a caught exception, just not the way this code is.

Depending on what quality you are looking at it is not throwing the exception in a different place. "throw" without a target rethrows the exception which is very different from throwing an exception. Primarily a rethrow does not reset the stack trace.
In this particular sample, the catch is pointless because it doesn't do anything. The exception is happily rethrown and it's almost as if the try/catch didn't exist.

I think the construction should be used for handling the exceptions you know you will be throwing inside your code; if other exception is raised, then just rethrow.
Take into account that
throw;
is different than
throw ex;
throw ex will truncate the stack to the new point of throwing, losing valuable info about the exception.
public void doSomething()
{
try
{
// actual code goes here
}
catch (EspecificException ex)
{
HandleException(ex);
}
catch (Exception ex)
{
throw;
}
}

It wouldn't be, ideally the catch block would do some handling, and then rethrow, e.g.,
try
{
//do something
}
catch (Exception ex)
{
DoSomething(ex); //handle the exception
throw;
}
Of course the re-throw will be useful if you want to do some further handling in the upper tiers of the code.

Doing something like that is fairly meaningless, and in general I try not to go down the road of doing meaningless things ;)
For the most part, I believe in catching specific types of exceptions that you know how to handle, even if that only means creating your own exception with more information and using the caught exception as the InnerException.

Sometimes this is appropriate - when you're going to handle the exception higher up in the call stack. However, you'd need to do something in that catch block other than just re-throw for it to make sense, e.g. log the error:
public void doSomething()
{
try
{
// actual code goes here
}
catch (Exception ex)
{
LogException (ex); // Log error...
throw;
}
}

I don't think just rethrowing the error would be useful. Unless you don't really care about the error in the first place.
I think it would be better to actually do something in the catch.
You can check the MSDN Exception Handling Guide.

I've seen instances where generic exceptions are caught like this and then re-packed in a custom Exception Object.
The difference between that and what you're saying is that those custom Exception objects hold MORE information about the actual exception that happened, not less.

Well for starters I'd simply do
catch
{
throw;
}
but basically if you were trapping multiple types of exceptions you may want to handle some locally and others back up the stack.
e.g.
catch(SQLException sex) //haha
{
DoStuff(sex);
}
catch
{
throw;
}

Depends on what you mean by "looks like this", and if there is nothing else in the catch block but a rethrow... if that's the case the try catch is pointless, except, as you say, to obfuscate where the exception occurred. But if you need to do something right there, where the error occurred, but wish to handle the exception furthur up the stack, this might be appropriate. But then, the catch would be for the specific exception you are handl;ing, not for any Exception

Generally having exception handling blocks that don't do anything isn't good at all, for the simple reason that it prevents the .Net Virtual Machine from inlining your methods when performance optimising your code.
For a full article on why see "Release IS NOT Debug: 64bit Optimizations and C# Method Inlining in Release Build Call Stacks" by Scott Hanselman

c# "finally" block that only runs on exceptions

Edit: I have looked at the answers code: NONE of them do what I want (I've checked). It would seem that there is no way to do what I want in native c#. I guess that's not a disaster just a shame given that .NET does support it (see accepted answer).
Thanks all.
I have c# code (part of a test framework that will never be run except under a debugger) like this who's point it to avoid actually catching the exception as that makes debugging the code in the unwound part of the stack a royal pain.
Bool bad = true;
try
{
MightThrow();
bad = false;
}
finally
{
if(bad) DoSomeLoggingOnFailure();
//// Does not catch!!!!
//// exception continues to unwind stack.
//// Note that re throwing the exception is NOT
//// the same as not catching it in the first place
}
is their a better way to do this?
A solution would have to behave exactly like that under the debugger with regards to un-caught exceptions. It would have to result in the only one first chance exception and the debugger breaking at the point that the exception was originally thrown, not in a catch block.
Specifically I need the debugger on un-caught exceptions to stop a in side MightThrow.
The following doesn't work because it fails to have the debugger break in the correct place
try { ... } catch { throw; }
And this doesn't work because it loses stack info (and also breaks in the wrong place).
try { ... } catch(Exception e) { throw e; }
I known that in D I could use a scope(failure) block

So, in .NET what you're asking for is theoretically possible, but it's not going to be easy.
CIL actually defines five types of exception handling block! The try, catch and finally ones you're used to in C#, and two others:
filter - similar to a catch block but can run arbitrary code to determine whether it wants to handle the error, rather than just matching on type. This block has access to the exception object, and has the same effect on the exception stack trace as a catch block.
fault - similar to a finally block, however it is only run when an exception occurs. This block does not have access to the exception object, and has no effect on the exception stack trace (just like a finally block).
filter is available in some .NET languages (e.g. VB.NET, C++/CLI) but is not available in C#, unfortunately. However I don't know of any language, other than CIL, that allows the fault block to be expressed.
Because it can be done in IL means not all is lost, though. In theory you could use Reflection.Emit to dynamically emit a function that has a fault block and then pass the code you want to run in as lambda expressions (i.e. one for the try part, one for the fault part, and so on), however (a) this isn't easy, and (b) I'm unconvinced that this will actually give you a more useful stack trace than you're currently getting.
Sorry the answer isn't a "here's how to do it" type thing, but at least now you know! What you're doing now is probably the best approach IMHO.
Note to those saying that the approach used in the question is 'bad practice', it really isn't. When you implement a catch block you're saying "I need to do something with the exception object when an exception occurs" and when you implement a finally you're saying "I don't need the exception object, but I need to do something before the end of the function".
If what you're actually trying to say is "I don't need the exception object, but I need to do something when an exception occurs" then you're half way between the two, i.e. you want a fault block. As this isn't available in C#, you don't have an ideal option, so you may as well choose the option that is less likely to cause bugs by forgetting to re-throw, and which doesn't corrupt the stack trace.

How about this:
try
{
MightThrow();
}
catch
{
DoSomethingOnFailure();
throw; // added based on new information in the original question
}
Really, that's all you did. Finally is for things that must run regardless of whether an exception occurred.
[Edit: Clarification]
Based on the comments you've been mentioning, you want the exception to continue being thrown without modifying its original stack trace. In that case, you want to use the unadorned throw that I've added. This will allow the exception to continue up the stack and still allow you to handle part of the exception. Typical cases might be to close network connections or files.
[Second edit: Regarding your clarification]
Specifically I need the debugger on
un-caught exceptions to stop at the
original point of the throw (in
MightThrow) not in the catch block.
I would argue against ever breaking a best-practice (and yes, this is a best-practice for partially handling exceptions) to add some minor value to your debugging. You can easily inspect the exception to determine the location of the exception throw.
[Final edit: You have your answer]
kronoz has thoughtfully provided you with the answer you sought. Don't break best practices -- use Visual Studio properly! You can set Visual Studio to break exactly when an exception is thrown. Here's official info on the subject.
I was actually unaware of the feature, so go give him the accepted answer. But please, don't go trying to handle exceptions in some funky way just to give yourself a hand debugging. All you do is open yourself up to more bugs.

If you're interested in the debugger simply stopping precisely where the exception occurred then have you considered first-chance exceptions?
If you open Tools|Exceptions then tick the Common Language Runtime Exceptions box, the debugger will stop at the point of exception regardless of any try/catch/finally blocks.
Update: You can specify the precise exception you wish to catch by expanding the [+] tree in the Exceptions dialog. Though of course it will fire every time any exception of the specified type[s] occur[s], you can switch it on and off at will even in the middle of a debugging session, so with judicious use of breakpoints you can get it to do your bidding. I used it successfully to get around the 'target of an invocation has thrown an exception' ball ache originating from using reflection to instantiate objects. Very useful tool in such circumstances. Also note the locals and stack trace should be firmly available as far as I recall (just did a quick test and they are available), so no problems there.
Of course if you want to log things then that is outside the scope of an IDE debugger; and in which case first-chance exceptions won't help you!
Give it a go at least; I found them very useful and they might be more appropriate for your issue than you think.

What's wrong with:
try
{
MightThrow();
}
catch
{
DoSomthingOnFailure();
throw;
}

For code that should only run on exceptions, use the catch block:
try
{
MightThrow();
}
catch (Exception ex)
{
// this runs only when there was an exception
DoSomthingOnFailure();
// pass exception on to caller
throw;
}
finally
{
// this runs everytime
Cleanup();
}

This is what you want. It will only call this method when an error occurs, and the "throw" statement will re-throw the exception with the callstack intact.
try
{
MightThrow();
}
catch
{
DoSomthingOnFailure();
throw;
}

A "finally" block that runs only on failure is called "catch" (with no parameters). :-)
Now, there is a small caveat. If you want to have a specialised "catch" case for a particular exception type and have a generic "catch" that works for all exceptions, you'll have to do a bit of a custom logic.
Thus, I would do something like:
try
{
MightThrow();
}
catch(MyException ex)
{
// Runs on MyException
MySpecificFailureHandler()
// Since we have handled the exception and can't execute the generic
// "catch" block below, we need to explicitly run the generic failure handler
MyGenericFailureHandler()
}
catch
{
// Runs on any exception hot handled specifically before
MyGenericFailureHandler()
// If you want to mimic "finally" behavior and propagate the exception
// up the call stack
throw;
}
finally
{
// Runs on any failure or success
MyGenericCleanupHandler();
}

Every example so far is losing the original StackTrace according to my tests. Here's a solution that should work for you.
private static void PreserveStackTrace(Exception exception)
{
MethodInfo preserveStackTrace = typeof(Exception).GetMethod("InternalPreserveStackTrace",
BindingFlags.Instance | BindingFlags.NonPublic);
preserveStackTrace.Invoke(exception, null);
}
try
{
MightThrow();
}
catch (Exception ex)
{
DoSomethingOnFailure();
PreserveStackTrace(ex);
throw;
}

How about only catching an exception that "MightThrow" does not throw?
Bool bad = true;
try
{
MightThrow();
bad = false;
}
catch (SomePrivateMadeUpException foo)
{
//empty
}
finally
{
if(bad) DoSomeLoggingOnFailure();
}

Let me recap your requirements the way I understand them:
You want some code that is run only when an exception is generated, in order to do some logging.
You want to run your test framework under debugger and break at the point at which the exception is thrown.
To meet your first requirement, you should write the code the way everybody suggested - using parameterless catch and throw.
To meet your second requirement while using the parameterless catch, you could configure your debugger to break when an exception is throw, not only when there's an unhandled exception. I suspect you know how to do it, but I'll put it here for answer completeness: in VS you can do that in Debug -> Exception -> Common Language Runtime Exceptions -> check the Thrown checkbox.
If you know that your app throws a lot of handled exceptions, that might not be an option for you. At that point, your only choice left to meet your first requirement is to either write the code to use finally for exception logging purposes or look into the direct IL emitting route as Greg Beech suggests.
However, whether the finally code is being executed depends on the debugger you are using. In particular, VS will break on an unhadled exception before the finally is executed and will not let you continue. Thus, unless you detach from the process at that point, your logging code will never be executed. In other words, the second requirement will interfere with meeting the first requirement.

You could encapsulate your logic in a custom class, something like:
public class Executor
{
private readonly Action mainActionDelegate;
private readonly Action onFaultDelegate;
public Executor(Action mainAction, Action onFault)
{
mainActionDelegate = mainAction;
onFaultDelegate = onFault;
}
public void Run()
{
bool bad = true;
try
{
mainActionDelegate();
bad = false;
}
finally
{
if(bad)
{
onFaultDelegate();
}
}
}
}
And use it as:
new Executor(MightThrow, DoSomeLoggingOnFailure).Run();
Hope this helps.

Isn't this the same as:
try
{
MightThrow();
}
catch (Exception e)
{
DoSomethingOnFailure();
throw e;
}
?

You could write, or have someone write for you, a small assembly in VB.net which implements a TryFaultCatchFinally(of T) method that accepts four delegates:
TryMethod -- An Action(of T) to perform the "Try" block.
FaultMethod -- A Predicate(Of T, Exception) which, if an exception occurs, will be called before any "finally" blocks run; if it returns true the Catch block will run--otherwise it won't.
CatchMethod -- An Action(Of T, Exception) to be performed if an exception had occurred and FaultMethod returned true; happens after "finally" blocks run.
FinallyMethod -- An Action(OF T, Exception, Boolean) to be performed as a "Finally" block. The passed-in exception will be null if TryMethod ran to completion, or will hold the exception that caused it to exit. The Boolean will be true if the exception was caught, or false otherwise.
Note that when the FaultMethod is executed, one may be able to examine the state of objects that caused the exception, before such state is destroyed by Finally blocks. One must use some care when doing this (any locks that were held when the exception was thrown will continue to be held) but the ability may still sometimes be handy, especially when debugging.
I'd suggest the routine look something like:
Shared Sub TryFaultCatchFinally(Of T)(ByVal TryProc As Action(Of T), _
ByVal FaultProc As Func(Of T, Exception, Boolean), _
ByVal CatchProc As Action(Of T, Exception), _
ByVal FinallyProc As Action(Of T, Exception, Boolean), _
ByVal Value As T)
Dim theException As Exception = Nothing
Dim exceptionCaught As Boolean = False
Try
TryProc(Value)
theException = Nothing
exceptionCaught = False
Catch Ex As Exception When CopyExceptionAndReturnFalse(Ex, theException) OrElse FaultProc(Value, Ex)
exceptionCaught = True
CatchProc(Value, Ex)
Finally
FinallyProc(Value, theException, exceptionCaught)
End Try
End Sub

No, I think this is a common idiom the way you have it.
EDIT
To be clear, the "catch" then "rethrow" strategies offer the same run-time semantics, however they change the experience when the VS debugger is attached. Tooling and maintenance is important; debugging often requires you to 'catch all first-chance exceptions' and if you end up with lots of 'spurious' first-chance exceptions due to catch-then-rethrow in your code, it really hurts the ability to debug the code. This idiom is about interacting well with the tooling, as well as clearly expressing the intent (you don't want to 'catch', decide can't handle, and rethrow, instead you just want to log that an exception did happen but let it pass on by).

Have you considered using the DebuggerStepThrough attribute?
http://msdn.microsoft.com/en-us/library/system.diagnostics.debuggerstepthroughattribute.aspx
[DebuggerStepThrough]
internal void MyHelper(Action someCallback)
{
try
{
someCallback();
}
catch(Exception ex)
{
// Debugger will not break here
// because of the DebuggerStepThrough attribute
DoSomething(ex);
throw;
}
}

With exception filters added in C# 6, one option is to make use of a false returning exception filter, like so:
void PerformMightThrowWithExceptionLogging()
{
try
{
MightThrow();
}
catch (Exception e) when (Log(e))
{
// Cannot enter here, since Log returns false.
}
}
bool Log(Exception e)
{
DoSomeLoggingOnFailure(e);
// Return false so the exception filter is not matched, and therefore the stack is kept.
// This means the debugger breaks where the exception actually happened, etc.
return false;
}
See https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/try-catch for more details on exception filters.

try
{
MightThrow();
}
catch
{
DoSomethingOnFailure();
}