Exception handling

  • Thread starter Thread starter Leif Eirik Olsen
  • Start date Start date
L

Leif Eirik Olsen

Hi,

I have a class Test with a property Active. Setter and getter is
implemented.
Setter ~
set
{
try
{
if (SomeValue) throw new Exception("Error");
else FActive = value
}
catch (System.Exception ex)
{ MessageBox.Show(ex.Message)}
}

In my main application that uses this Test class I code something like this:
Test aTest = new Test;
aTest.Active = true;
Do other stuff1
Do other stuff2
....

My problem: How do I break execution on the line "aTest.Active = true;" if
the setting of the Active property raised an exception ?
In other words: I do not want to execute "do other stuff1 & 2" if an
exception was raised on the previous line.

I know I can solve this by doing this:
Test aTest = new Test;
aTest.Active = true;
if (aTest.Active)
{
Do other stuff1
Do other stuff2
...
}
, but this does not feel right :)

any hints or help greatly appriciated.

regards,
Leo
 
Why catch the exception that you immediately throw? Let it bubble up.
Surround your "aTest.Active = true;" line with a try/catch. That way, the
code that sets the Active property will be notified when the error occurs,
which is the intended behavior.

Derrick
 
Setter ~
set
{
try
{
if (SomeValue) throw new Exception("Error");
else FActive = value
}
catch (System.Exception ex)
{ MessageBox.Show(ex.Message)}
}

}

In your main application that uses this Test class :

Test aTest = new Test;
try
{
aTest.Active = true;
}
catch
{
throw;
}


Do other stuff1
Do other stuff2
 
news.microsoft.com said:
In your main application that uses this Test class :

Test aTest = new Test;
try
{
aTest.Active = true;
}
catch
{
throw;
}


Do other stuff1
Do other stuff2
Click to expand...

Thanks, but I do not think that will help much, as the "aTest.Active = true
Excpetion) is already handeled in the Setter, thus you suggested try -
catch -> throw will never fire. True?

regards,
Leo
 
Derrick said:
Why catch the exception that you immediately throw? Let it bubble up.
Surround your "aTest.Active = true;" line with a try/catch. That way, the
code that sets the Active property will be notified when the error occurs,
which is the intended behavior.

Derrick
Click to expand...

Yes, mabe your right, but then I end up with a lot of exception handeling in
my main application, instead of in my support-classes where I feel the
exception handeling belongs.
These things function a bit different in Delphi (pre .net where I've done
most of my work), mabe it is just another way of doing the same thing, and
I'll just need do get used to it :)

Thanks again,
Leo
 
Oh, sorry, missed that. I think the code below shall solve your problems,
also, you wont need to write exception handling messages everywhere.

Setter ~
set
{
try
{
if (SomeValue) throw new Exception("Error");
else FActive = value
}
catch (System.Exception ex)
{
throw;
}
}


Test aTest = new Test;
try
{
aTest.Active = true;
}
catch
{
throw //or messagebox.show is this is the end point;
}


Do other stuff1
Do other stuff2
 
hi,

well that is the point of the exception after all, to inform to the caller
that the value used is not valid. , otherwise there is no need to throw an
exception and the code will look like this:

set
{

if (SomeValue)
MessageBox.Show(ex.Message);
else
else FActive = value
}


easier I think. I anyway see no point in that, why you do not set the value
of FActive to true somewhere?


cheers,
 
Ignacio Machin ( .NET/ C# MVP ) said:
hi,

well that is the point of the exception after all, to inform to the caller
that the value used is not valid. , otherwise there is no need to throw an
exception.....
Click to expand...

Agreed.

Well, my problem is not a all 'show stopper', I'm just trying to understand
how to layout my code right.

The Test class with the property Active I'm talking about is in fact a
comport wrapper class, and the Active property opens/closes the selected
comport. In this case a bluetooth enabled comport. Not sure all agree with
me, but I would prefer to do the exception handeling at the 'property
setting level' in this case (if the comport fails to open, that is :)). If
I do this I get the undesired result that I, in my main application, have to
code like this:

aTest.Active = true;
if (aTest.Active) //do check because previous line could have raised an
exception and not set active to true
{
do other stuff...
}

I think what I'll do (don't laugh:))....I'll replace the Active property
with two methods OpenCom and CloseCom both returning a bool indicating
success or not. Then I can write my code (in main application) like this
(feels better):

if (aTest.OpenCom())
{
do other suff
}



regards,
Leo
 
Back
Top