We Keep Coding

constructor.Invoke(parameters) is giving me an error

I'm trying to invoke an instance using constructor.Invoke and also passing some parameters in it, but I'm getting
System.Reflection.TargetInvocationException: 'Exception has been thrown by the target of an invocation.'
Any inputs would be helpful
Thanks

TargetInvocationException basically means that the member could be invoked successfully and the exception occurred in the invoked member itself. To differentiate it from other issues (eg. wrong instance, invalid number or type of parameters, etc.) the exception thrown by the invoked member is wrapped into a TargetInvocationException. Just look at its InnerException to see what happened.
If you want to 'unwrap' such exceptions as if you called the constructor without reflection you can do something like this:
try
{
return myConstructorInfo.Invoke(parameters);
}
catch (TargetInvocationException e)
{
// we could just throw e.InnerException but that would corrupt the
// original stack trace, showing this line as the source of the exception
ExceptionDispatchInfo.Capture(e.InnerException).Throw();
throw; // unreachable, just to satisfy the compiler if there is no return later
}

Why is this SocketException not caught by a generic catch routine?

Our company provides a network component (DLL) for a GUI application.
It uses a Timer that checks for disconnections. If it wants to reconnect, it calls:
internal void timClock_TimerCallback(object state)
{
lock (someLock)
{
// ...
try
{
DoConnect();
}
catch (Exception e)
{
// Log e.Message omitted
// Raise event with e as parameter
ErrorEvent(this, new ErrorEventArgs(e));
DoDisconnect();
}
// ...
}
}
So the problem is, inside of the DoConnect() routine a SocketException is thrown (and not caught). I would assume, that the catch (Exception e) should catch ALL exceptions but somehow the SocketException was not caught and shows up to the GUI application.
protected void DoConnect()
{
//
client = new TcpClient();
client.NoDelay = true;
// In the following call the SocketException is thrown
client.Connect(endPoint.Address.ToString(), endPoint.Port);
// ... (login stuff)
}
The doc confirmed that SocketException extends Exception.
The stacktrace that showed up is:
TcpClient.Connect() -> DoConnect() -> timClock_TimerCallback
So the exception is not thrown outside the try/catch block.
Any ideas why it doesn't work?

If ErrorEvent really raises another exception (per the comment), then DoDisconnect() is never executed.
Otherwise, the exception you see might be coming form DoDisconnect()

I wrote a little program and was unable to reproduce, a SocketException was caught inside a TimerCallback just fine.
So I suggest you re-think your analysis, the problem may not be what you think it is. A few suggestions:
run it outside the Timer. T|hat takes the threading out of the loop.
run it in the debugger. Where does the exception really occur?
step through the exception handling. Is ErrorEvent doing what it should?

Could you post the DoConnect() code?
Also things to try:
Can you catch it in the DoConnect()?
Try catching the specific exception instead of just the generic.
How does it react if you use debug mode?

Your timClock_TimerCallback isn't called in the same thread as the catch-statement wants to catch an exception. You should catch the exception inside timClock_TimerCallback and then call a method which invokes itself and then rethrow the exception in the right thread.
Not sure this will work, but you could give it a try.

How can I rethrow an Inner Exception while maintaining the stack trace generated so far?

Duplicate of: In C#, how can I rethrow InnerException without losing stack trace?
I have some operations that I invoke asynchronously on a background thread. Sometimes, things go bad. When this happens, I tend to get a TargetInvocationException, which, while appropriate, is quite useless. What I really need is the TargetInvocationException's InnerException, like this:
try
{
ReturnValue = myFunctionCall.Invoke(Target, Parameters);
}
catch (TargetInvocationException err)
{
throw err.InnerException;
}
That way, my callers are served up with the REAL exception that occured. The problem is, that the throw statement seems to reset the stack trace. I'd like to basically rethrow the inner exception, but keep the stack trace it originally had. How do I do that?
CLARIFICATION:
The reason I want only the inner exception is that this class tries to 'abstract away' the whole fact that these functions (delegates supplied by caller) are run on other threads and whatnot. If there is an exception, then odds are it has nothing to do with being run on a background thread, and the caller would really like the stack trace that goes into their delegate and finds the real issue, not my call to invoke.

It is possible to preserve the stack trace before rethrowing without reflection:
static void PreserveStackTrace (Exception e)
{
var ctx = new StreamingContext (StreamingContextStates.CrossAppDomain) ;
var mgr = new ObjectManager (null, ctx) ;
var si = new SerializationInfo (e.GetType (), new FormatterConverter ()) ;
e.GetObjectData (si, ctx) ;
mgr.RegisterObject (e, 1, si) ; // prepare for SetObjectData
mgr.DoFixups () ; // ObjectManager calls SetObjectData
// voila, e is unmodified save for _remoteStackTraceString
}
This wastes a lot of cycles compared to InternalPreserveStackTrace, but has the advantage of relying only on public functionality. Here are a couple of common usage patterns for stack-trace preserving functions:
// usage (A): cross-thread invoke, messaging, custom task schedulers etc.
catch (Exception e)
{
PreserveStackTrace (e) ;
// store exception to be re-thrown later,
// possibly in a different thread
operationResult.Exception = e ;
}
// usage (B): after calling MethodInfo.Invoke() and the like
catch (TargetInvocationException tiex)
{
PreserveStackTrace (tiex.InnerException) ;
// unwrap TargetInvocationException, so that typed catch clauses
// in library/3rd-party code can work correctly;
// new stack trace is appended to existing one
throw tiex.InnerException ;
}

No, that isn't possible. Your only real opportunity is to follow the recommended pattern and throw your own exception with the appropriate InnerException.
Edit
If your concern is the presence of the TargetInvocationException and you want to disregard it (not that I recommend this, as it could very well have something to do with the fact that it's being run on another thread) then nothing is stopping you from throwing your own exception here and attaching the InnerException from the TargetInvocationException as your own InnerException. It's a little smelly, but it might accomplish what you want.

There is a way of "resetting" the stack trace on an exception by using the internal mechanism that is used to preserve server side stack traces when using remoting, but it is horrible:
try
{
// some code that throws an exception...
}
catch (Exception exception)
{
FieldInfo remoteStackTraceString = typeof(Exception).GetField("_remoteStackTraceString", BindingFlags.Instance | BindingFlags.NonPublic);
remoteStackTraceString.SetValue(exception, exception.StackTrace);
throw exception;
}
This puts the original stack trace in the _remoteStackTraceString field of the exception, which gets concatenated to the newly reset stack trace when the exception is re-thrown.
This is really a horrible hack, but it does achieve what you want. You are tinkering inside the System.Exception class though so this method may therefore break in subsequent releases of the framework.

Although you may feel that the TargetInvocationException is "useless", it's the reality. Don't try to pretend that .NET didn't take the original exception and wrap it with a TargetInvocationException and throw it. That really happened. Some day, you might even want some piece of information that comes from that wrapping - like maybe the location of the code that threw the TargetInvocationException.

You can't do that. throw always resets the stack trace, unless used without parameter. I'm afraid your callers will have to use the InnerException...

Using the "throw" keyword with an exception will always reset the stack trace.
The best thing to do is to catch the actual exception you want, and use "throw;" instead of "throw ex;". Or to throw your own exception, with the InnerException that you want to pass along.
I don't believe what you want to do is possible.

As others have said, use the "throw" keyword without adding to it to keep the exception chain intact. If you need that original exception (assuming that is what you mean) then you could call Exception.GetBaseException() at the end of your chain to get the Exception that started it all.

It is possible with .net 4.5:
catch(Exception e)
{
ExceptionDispatchInfo.Capture(e.InnerException).Throw();
}

C# Time of finally execution

Take this code:
using System;
namespace OddThrow
{
class Program
{
static void Main(string[] args)
{
try
{
throw new Exception("Exception!");
}
finally
{
System.Threading.Thread.Sleep(2500);
Console.Error.WriteLine("I'm dying!");
System.Threading.Thread.Sleep(2500);
}
}
}
}
Which gives me this output:
Unhandled Exception: System.Exception: Exception!
at OddThrow.Program.Main(String[] args) in C:\Documents and Settings\username
\My Documents\Visual Studio 2008\Projects\OddThrow\OddThrow\Program.cs:line 14
I'm dying!
My question is: why does the unhandled exception text occur before the finally's? In my mind, the finally should be excuted as the stack unwinds, before we even know that this exception is unhandled. Note the calls to Sleep() - these occur after the unhandled exception is printed, as if it was doing this following:
Unhandled exception text/message
Finally blocks.
Terminate application
According to the C# standard, §8.9.5, this behaviour is wrong:
In the current function member, each try statement that encloses the throw point is examined. For each statement S, starting with the innermost try statement and ending with the outermost try statement, the following steps are evaluated:
If the try block of S encloses the throw point and if S has one or more catch clauses, the catch clauses are examined in order of appearance to locate a suitable handler for the exception. The first catch clause that specifies the exception type or a base type of the exception type is considered a match. A general catch clause (§8.10) is considered a match for any exception type. If a matching catch clause is located, the exception propagation is completed by transferring control to the block of that catch clause.
Otherwise, if the try block or a catch block of S encloses the throw point and if S has a finally block, control is transferred to the finally block. If the finally block throws another exception, processing of the current exception is terminated. Otherwise, when control reaches the end point of the finally block, processing of the current exception is continued.
If an exception handler was not located in the current function member invocation, the function member invocation is terminated. The steps above are then repeated for the caller of the function member with a throw point corresponding to the statement from which the function member was invoked.
If the exception processing terminates all function member invocations in the current thread, indicating that the thread has no handler for the exception, then the thread is itself terminated. The impact of such termination is implementation-defined.
Where am I going wrong? (I've got some custom console error messages, and this is in-the-way. Minor, just annoying, and making me question the language...)

The standard's statements about the order of execution are correct, and not inconsistent with what you are observing. The "Unhandled exception" message is allowed to appear at any point in the process, because it is just a message from the CLR, not actually an exception handler itself. The rules about order of execution only apply to code being executed inside the CLR, not to what the CLR itself does.
What you've actually done is expose an implementation detail, which is that unhandled exceptions are recognised by looking at a stack of which try{} blocks we are inside, rather than by actually exploring all the way to the root. Exceptions may or may not be handled by looking at this stack, but unhandled exceptions are recognised this way.
As you may be aware, if you put a top-level try{}catch{} in your main function, then you will see the behaviour you expect: each function's finally will be executed before checking the next frame up for a matching catch{}.

I could be way off base in the way I'm reading things...but you have a try finally block without a catch.
Juding by the description you posted, since the Exception is never caught, it bubbles up to the caller, works it's way up through the stack, is eventually unhandled, the call terminates, and then the finally block is called.

The output is actually from the default CLR exception handler. Exception Handlers occur before the finally block. After the finally block the CLR terminates because of the unhandled exception (it can't terminate before, as c# guarantees [1] that the finally clause is called).
So I'd say it's just standard behaviour, exception handling occurs before finally.
[1] guranteed during normal operation at least in absence of internal runtime errors or power outage

To add more into the mix, consider this:
using System;
namespace OddThrow
{
class Program
{
static void Main()
{
AppDomain.CurrentDomain.UnhandledException +=
delegate(object sender, UnhandledExceptionEventArgs e)
{
Console.Out.WriteLine("In AppDomain.UnhandledException");
};
try
{
throw new Exception("Exception!");
}
catch
{
Console.Error.WriteLine("In catch");
throw;
}
finally
{
Console.Error.WriteLine("In finally");
}
}
}
}
Which on my system (Norwegian) shows this:
[C:\..] ConsoleApplication5.exe
In catch
In AppDomain.UnhandledException
Ubehandlet unntak: System.Exception: Exception!
ved OddThrow.Program.Main() i ..\Program.cs:linje 24
In finally

Although not completely expected, the program does behave as it should. A finally block is not expected to be run first, it is only expected to be run always.
I adjusted your sample:
public static void Main()
{
try
{
Console.WriteLine("Before throwing");
throw new Exception("Exception!");
}
finally
{
Console.WriteLine("In finally");
Console.ReadLine();
}
}
In this case you will get the nasty unhandled exception dialog, but afterwards the console will output and wait for input, thus executing the finally, just not before windows itself catches the unhandled exception.

A try/finally without a catch will use the default handler which does exactly what you see. I use it all the time, e.g., in cases where handling the exception would be covering an error but there's still some cleanup you want to do.
Also remember that output to standard error and standard out are buffered.

The try-catch-finally blocks are working exactly as you expected if they are caught at some point. When I wrote a test program for this, and I use various nesting levels, the only case that it behaved in a way that matched what you described was when the exception was completely unhandled by code, and it bubbled out to the operating system.
Each time I ran it, the OS was what created the error message.
So the issue is not with C#, it is with the fact that an error that is unhandled by user code is no longer under the control of the application and therefore the runtime (I believe) cannot force an execution pattern on it.
If you had created a windows form application, and wrote all your messages to a textbox (then immediately flushing them) instead of writing directly to the console, you would not have seen that error message at all, because it was inserted into the error console by the calling application and not by your own code.
EDIT
I'll try to highlight the key part of that. Unhandled exceptions are out of your control, and you cannot determine when their exception handler will be executed. If you catch the exception at some point in your application, then the finally blocks will be executed before the lower-in-the-stack catch block.

To put a couple of answers together, what happens is that as soon as you have a Unhandled Exception a UnhandledExceptionEvent is raised on the AppDomain, then the code continues to execute (i.e. the finally). This is the MSDN Article on the event

Next try:
I believe this case isn't mentioned in the c# standard and I agree it seems to almost contradict it.
I believe the internal reason why this is happening is somewhat like this:
The CLR registers its default exception handler as SEH handler into FS:[0]
when you have more catches in your code, those handlers are added to the SEH chain. Alternatively, only the CLR handler is called during SEH handling and handles the CLR exception chain internally, I don't know which.
In your code when the exception is thrown, only the default handler is in the SEH chain. This handler is called before any stack unrolling begins.
The default exception handler knows that there are no exception handler registered on the stack. Therefore it calls all registered UnhandledException handler first, then prints its error message and marks the AppDomain for unloading.
Only after that stack unrolling even begins and finally blocks are called according the c# standard.
As i see it, the way the CLR handles unhandled exception isn't considered in the c# standard, only the order in which finallys are called during stack unrolling. This order is preserved. After that the "The impact of such termination is implementation-defined." clause takes effect.

What's the essential difference between the two HandleException() methods of Exception Handling Application Block (Ent Lib 4.1)

In the most recent version (4.1, released October 2008) of The Microsoft Enterprise Library's Exception Handling Application Block, there are two HandleException() method signatures, and I am a bit lost on the intent for these, especially since neither the documentation, intellisense, nor the QuickStart apps intimate any meaningful difference.
Here are the two signatures:
bool HandleException(Exception exceptionToHandle, string policyName);
bool HandleException(Exception exceptionToHandle, string policyName, out Exception exceptionToThrow);
All of the examples I have found use the first, as in this example straight out of the XML documentation comments on the actual method:
try
{
Foo();
}
catch (Exception e)
{
if (ExceptionPolicy.HandleException(e, name)) throw;
}
And here, from the same source (the XML doc comments for the method), is an example of using the second:
try
{
Foo();
}
catch (Exception e)
{
Exception exceptionToThrow;
if (ExceptionPolicy.HandleException(e, name, out exceptionToThrow))
{
if(exceptionToThrow == null)
throw;
else
throw exceptionToThrow;
}
}
So, my question is, what does using the second one give you that the first does not? This should probably be obvious to me, but my head is a mess today and I don't really want to keep banging my head against the proverbial wall any longer. :)
No speculations, please; I hope to hear from someone that actually knows what they are talking about from experience using this.

If you use a replace handler in the enterprise library config, your replacement exception is returned by means of the second signature .. , out Exception exceptionToThrow).

The main difference between the two method overloads is that
bool HandleException(Exception exceptionToHandle, string policyName);
will throw an exception if the PostHandlingAction is set to ThrowNewException.
Whereas the second method overload:
bool HandleException(Exception exceptionToHandle, string policyName, out Exception exceptionToThrow);
does not throw an exception in that case but instead returns the exception to be rethrown as an out parameter.
Actually, both calls invoke the same core code but the second method overload catches the thrown Exception and returns it to the caller.
So the second overload gives you a bit more control since you could perform some additional logic before throwing. It also standardizes the API in the sense that if you use the second HandleException method with the out parameter Enterprise Library will never intentionally handle your exception and throw it for you. i.e. The first method sometimes throws and sometimes relies on you to rethrow (in the case of NotifyRethrow) but the second method always returns and lets the caller throw/rethrow.

I believe you are not allowed to throw your original exceptions across WCF service boundaries, this is a security feature (really to make sure that sensitive error information is not propagated through the service chain). Therefore a new execption can be created and passed in via the second parameter out Exception exceptionToThrow) and given a specific exception message and type by means of your configuration (enterprise library replace exception). One example of which is:
try
{
throw new InvalidCastException();
}
catch (InvalidCastException ex)
{
Exception ex1;
bool rethrow = ExceptionPolicy.HandleException(ex, "ReplacePolicy1", out ex1);
if (rethrow)
{
throw new FaultException<ApplicationException>((ApplicationException)ex1, ex1.Message);
}
}
Throwing a FaultException (with a Fault contract set up on the WCF operation) prevents the WCF Service from reporting a faulted state error message in your calling application / Service.
Without the second signature i would struggle with error simplification / propagation across WCF service boundries.
Thanks,
Paul.
(mod to code 8/7/09 - correction comment from John, thanks)