I'm using a backgroundworker (in VSE2005 for C#) and have the following problem :
In the 'dowork' method I have a try/catch that handles exceptions that might occur and then rethrow them for the 'workcompleted' method have a proper error state.
The problem is that when an exception occurs, I get an unhandled exception error message pointing to the 'throw ex;' in the catch block (see code below), because of course ex is not being handled, at least not right there.
The problem is that in order to test for the error status of you background _dowork method in your 'workcompleted' method you rely on the RunWorkerCompletedEventArgs e parameter that is set to error only when you issue an exception from within the dowork code.
In other words, when an exception occurs, if I do not rethrow it, the workcompleted method will consider there was no exception. But if I do rethrow it, then the dowork method considers it's not being handled!
Heeeelp!
private
void bgw_DoWork(object sender, DoWorkEventArgs ea){
//some variable declarations and initialization
try{
//do some odbc querying
}
catch (Exception ex){
//stuff..
throw ex; <== this is the problem}
//
private
void bgw_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e){
if (e.Error != null) <= will always fail when no rethrowing in the dowork method{
//do something
}
else{
//do something else
}
}
Thanks,
MM.
Managing exceptions in a backgroundworker
jcviera
Sergey,
I haven't tried that, it should work. But does that mean there's a bug in VSE C#
If so I should report it. Were you able to reproduce the problem
Thanks,
MM
Kevin LZJ
Well, I think it's a bug.
I don't try to reproduce it, but I think you should report it to http://lab.msdn.microsoft.com/productfeedback/default.aspx, they will try to reproduce and fix it.
If you report - post here link to report, so I will try to reproduce and validate it. This will help to get this problem solved faster.
twostepted
I mean this tactics:
string
ErrorMessage = "";void
bgw_DoWork(object sender, DoWorkEventArgs ea){
//some variable declarations and initialization try{
//do some odbc querying ErrorMessage = "";}
catch (Exception ex)
{
}
}
void
bgw_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e){
if (e.Error != null || !string.IsNullOrEmpty(ErrorMessage)){
//do something MessageBox.Show(ErrorMessage);}
else{
//do something else}
}
Donna M. Singel
Hi Meta,
I am marking the above reply from Sergey as Answer.If you think your post is still not answered, you can still re-open the post by clicking on Unmark as Answer.
Thank you,
Bhanu.
Klaus Loffelmann
Hi!
If rethrow do not work (strange in fact, I will check this later), then you can use theese workarounds:
1. replace catch with finally if you use clean up code there (or using statement)
2. declare "Exception Error = null;", set it when you catch and check it in Completed event.
Mayuresh
Sergey,
Uh, I'm afraid you lost me there.
1- Did you check if throw worked for you It doesn't for me, it's fine at compile time and even runtime until an exception occurs, and then it tells me the one I'm (re)throwing isn't handled.
2- So in my _dowork i do
...
catch(Exception ex){
Exception Error = null; (Error is the name of the exception, why another name than the one declared as an argument in the catch )
...
}
and I check it in the workcompleted But how is it set
Why would it be anything but null if it was merely declared and never thrown
I'm a little lost there.
Thanks,
MM.
Dave Waterworth
I finally solved it !
There's no bug, just some constraints on where/when to handle the e.error result.
The cause of all my problems was that I had a few lines in the 'runworkercompleted()' method where I was checking something BEFORE testing e.error.
It seems that if the e.error check isn't the first thing you do in the runworkercompleted then the system doesn't recognize you're handling the exception and crashes with the 'unhandled exception' error.
I moved the if(e.error != null) at the very beginning of the runworkercompleted method and all my worries evaporated!
Of course I deserve some mental slaps for 1) not having thought of that earlier and most importantly 2) for not having shown those extra lines in the original post describing the incident.
Grateful thanks to all those who tried to help.
MetaMeta