Exception Handling without closing program

[Sythion]

Hello,

I've written a small program for a small business, and I'm looking to handle some exceptions in a special way. Specifically, when an attempt to connect to the database fails, I would like to pop up a Windows.Form displaying the exception and giving the user some debug tips.

Of course, if I catch the exception and throw it forward it closes the entire application, and if I simply catch the exception and don't throw it further it will run into other exceptions, causing the same issue.

Is there some way I can either cause the current thread to close (opening the information form in another thread), or handle the exception without causing the program to close?

[kungpaoshizi]

create the form on the fly with custom text within the (catch exception e) and showdialog() to pause the thread?
or just use a goto hehe

[BigEd781]

The method that creates the connection to the DB should not be doing anything UI related. That method will simply throw/bubble-up an exception and the UI code can handle it.

[harrisunderwork]

"and if I simply catch the exception and don't throw it further it will run into other exceptions, causing the same issue."

Why so if you already caught the exception, why would you proceed, there is definitely some flaw in logic.

[Sythion]

"and if I simply catch the exception and don't throw it further it will run into other exceptions, causing the same issue."

Why so if you already caught the exception, why would you proceed, there is definitely some flaw in logic.

Perhaps communication more than logic. I don't want it to proceed. I just want it to throw up a UI telling the user some troubleshooting tips, since I won't be around. (Make sure database computer is on, connected, and that database has started, etc). How do I stop it from proceeding without killing the entire application?

By default, if I just catch the exception and don't throw another exception, the program continues to run, and since there's no connection to the DB it fails somewhere else further down the line.

[BigEd781]

Did you read my answer?

[Sythion]

Did you read my answer?

Yes. That sounds like a good design practice. I'll keep my connection code based on connection only.

The only solution I've seen(and haven't tried yet) is kungpaoshizi's. That might work, but it seems like there should be something basic about handling exceptions that I'm missing, and I'd like to find out what that is if possible.

[BigEd781]

I don't quite understand

// in the UI
try
{
    myDbObject.Connect( ... );
}
catch (SomeDBConnectionException)
{
    MessageBox.Show( "Couldn't Connect" );
}

[Sythion]

I don't quite understand

// in the UI
try
{
    myDbObject.Connect( ... );
}
catch (SomeDBConnectionException)
{
    MessageBox.Show( "Couldn't Connect" );
}

The problem is after a connect statement there's nothing telling the program to stop, so it will continue on and try to do something with the failed connection, generating a new exception which closes the program.

Putting the try block around everything might work, but then I'd be spouting out technical stack information instead of the troubleshooting steps I want the user to have.

Maybe my best option is to make some sort of a parser to run the error message through to generate the feedback I want.

[dglienna]

You could set a flag, and not proceed if the flag is tripped, or generate a trigger to a different error handler

[BigEd781]

Well, there is. You can exit the program from the catch block, you can disable controls until it succeeds, etc.

[TheGreatCthulhu]

[...] but then I'd be spouting out technical stack information instead of the troubleshooting steps I want the user to have.

Well, you're right about that not being very desirable...
Exceptions, in their raw, natural state, are in fact meant for the the developer, not the end user, and thus - from a developer's perspective - contain quite a bit of important information that could help solve the problem.

If your code fails to connect, and then, as you said, it just continues to do it's business as if nothing is wrong, tossing calls to an invalid object, then maybe it could be redesigned to behave more appropriately?
It may not require a lot of work - see what you can do.

Then, when you fixed all that was in your power to fix, and a possibility for an exception remains, you can elegantly catch and handle it.
As BigEd781 said, you can do pretty much anything. Handle any internal stuff that needs to be restored to a valid state, show an appropriate message to the user, or more.
You can ask the user if the app should try again or quit, or you can check the app's settings to see how it should behave, or you can present the user with a freakin Snake game to kill time untill the connection is established .