Why does throw crash my program but return doesn't?

Question

I am trying to catch exceptions for my form client not being able to establish a connection to a server with this in the Connect callback:

try
{
    client.EndConnect(async);
}
catch (Exception e)
{
    client.Close();

    return;
}

This works fine but this behavior is encapsulated in to a class so I want to call throw; instead of return; so that the client class can handle it instead, like so:

try
{
    client.Connect(host, port);
}
catch
{
    Console.WriteLine("Could not connect to: " + host + ":" + port.ToString());
}

So why not just call throw; then? Well, for some reason if I call throw;, throw new Exception();, or basically anything other than return; the program failsfast. I'm really not sure what's causing this. I tried removing client.Close(); to see if it was the problem but nothing. If I don't call return; the program just immediately exits with no error.

Anyone know what's going on here?

Edit: I do not understand why I am getting downvoted so much. I showed how I am attempting to catch these exceptions and am asking why they are not working properly. I think the problem may be (not sure, just came up with this) because within the asynchronous callback, because it is a new thread in the ThreadPool, calling throw; does not do anything because, because it is not synchronous, there is nothing to throw back to and the application dies. Even with this knowledge, I am not sure how to solve this problem unless I put some sort of try-catch on the entire program.

I suppose a solution could be just sticking with return; because there is nothing to throw back to (due to the asynchronous callback nature of the method) and instead raise an event indicating a failure of connection. Regardless, many thanks for the downvotes and helping me solve this problem. Oh wait...

well are you catching the exception that you throw somewhere? If not yes, your process will be terminated. — BrokenGlass, Sep 26 '11 at 03:35
Pal, every throw must be caught some where else. Now show us the code where your calling and catching an exceptions. — Zenwalker, Sep 26 '11 at 03:37
Why not handle the exception there itself ? Are you catching after throwing it ? — V4Vendetta, Sep 26 '11 at 03:37
BrokenGlass: I included the code where I show where I am catching it. The second code snippet is where I am catching it. The first one is the async callback from within the `client.Connect(host, port);` call. — Ryan Peschel, Sep 26 '11 at 03:58

score 1 · Accepted Answer · answered Sep 26 '11 at 04:26

1

What's happening is that the EndConnect is not happening on the same thread as your BeginConnect. When EndConnect throws an exception, it is caught by the worker thread's unhandled exception handler, which fails fast (the other option is that it gets ignored and you never find out that your code isn't working).

You have to come up with a way to tell your main form thread that the connect failed.

answered Sep 26 '11 at 04:26

Gabe

84,912
12
139
238

Using events and they seem to work fine. Is there an alternative where-in I could use a try-catch on the Connect method in the client code? Would probably make more sense. If not that's fine. Events are nice too. – Ryan Peschel Sep 26 '11 at 04:48
1

You can't catch an exception from the `Connect` method because it's not that method's code that throwing the exception. The `Connect` method may have already returned by the time the connect fails and an exception would be thrown, leaving nobody left to catch it. – Gabe Sep 26 '11 at 04:51

score 0 · Answer 2 · edited May 23 '17 at 12:19

As others have pointed out, you'll need to catch your exception one way or another to avoid program termination.

For some ideas on how you can do that "globally", see How to catch ALL exceptions/crashes in a .NET app. Whether this is actually a good idea depends on the specific needs of your program...

Relevant for WinForms:

Can't tell based on your question alone, but in case this is actually a WinForms application, you may need to be cognizant of the difference in behavior of modal forms that throw exceptions, depending on whether the debugger is active or not. Let's say we have two forms - the second one is shown as a modal child of the first one:

If application was started through debugger, second form is closed and and stack unwinding goes all the way to the first form's catch block (if any).
If application is started outside debugger, stack unwinding stops before second form is closed and generic exception message is displayed. The second form stays open and catch block in the first form is never reached.

Why does throw crash my program but return doesn't?

2 Answers2

Relevant for WinForms: