Exception

  • Thread starter Thread starter Tony Johansson
  • Start date Start date
T

Tony Johansson

Hello!

First of all All Exceptions must be derived from class Exception.
I just wonder what is the point to have this catch statement alone as you
can see below.

These two try.. catch below are doing the same thing.
The first one catch an Exception and all classes derived from it because
every exception must be derived from class Exception
The second catch everything. Here everything is all Exeption and all classes
below.

So as summary catch and catch(Exception) is doing the same thing

You can't for example do something like thow 2 or throw "hej";

try
{
//here we thow some kind of exception
}
catch(Exception)
{
}


try
{
//here we thow some kind of exception
}
catch
{
}

//Tony
 
Tony Johansson said:
Hello!

First of all All Exceptions must be derived from class Exception.
I just wonder what is the point to have this catch statement alone as you
can see below.

These two try.. catch below are doing the same thing.
The first one catch an Exception and all classes derived from it because
every exception must be derived from class Exception
The second catch everything. Here everything is all Exeption and all
classes below.

So as summary catch and catch(Exception) is doing the same thing

You can't for example do something like thow 2 or throw "hej";

try
{
//here we thow some kind of exception
}
catch(Exception)
{
}


try
{
//here we thow some kind of exception
}
catch
{
}

//Tony
Click to expand...
Hi,

You can choose the exception class you want to catch,
so you can say: catch(ArgumentOutOfRangeException)
or: catch(IOException) or if you want to you could
do: catch(Exception).

The only thing is that the c# language gives you the option
to omit the exception type and simply catch Exception
and all its descendants.

And you can also do:

try
{
}
catch (Exception e)
{
textBox1.AppendText(e.Message);
}

One little note: generally speaking, it is not 'ok' to catch
every type of exception. Try to catch only the exceptions
that you expect to happen. Every other exception is
possibly a bug and you (probably) won't want to handle it
or don't have to code to handle it.

For example, if you are calling some file io functions of your
own design, you know you can expect something like an
IOException. But if you have a self-made bug in your code,
one that you are unaware of, and that bug throws a
FormatException for example, you probably don't want
to handle that as a file io error.

Besides that, if you catch everything and an exception due
to a bug gets thrown, you or your client might not be able
to see/report the bug and thus you can't fix it.

regards,
Marcel
 
Hello!

But as I mentioned these two try...catch are doing the same thing can we
agree baout that ?
try

//Tony
 
First of all All Exceptions must be derived from class Exception.
I just wonder what is the point to have this catch statement alone as you
can see below.

These two try.. catch below are doing the same thing.
The first one catch an Exception and all classes derived from it because
every exception must be derived from class Exception
The second catch everything. Here everything is all Exeption and all
classes below.

So as summary catch and catch(Exception) is doing the same thing

You can't for example do something like thow 2 or throw "hej";

try
{
//here we thow some kind of exception
}
catch(Exception)
{
}


try
{
//here we thow some kind of exception
}
catch
{
}
Click to expand...

The only time I would ever explicitly add "Exception" is if I were going to
assign a variable that I can then inspect inside the catch [e.g., catch
(Exception ex)]. As written above, (Exception) is superfluous.

As a side note, I highly recommend you use "ex" for your catch variable
names and not "e" as many examples do, because if you happen to be in an
event handler, the event variable is invariably (HAR!) named "e" and you'll
have a conflict.
 
"Jeff Johnson" <[email protected]> schreef in bericht
(snip)
As a side note, I highly recommend you use "ex" for your catch variable
names and not "e" as many examples do, because if you happen to be in an
event handler, the event variable is invariably (HAR!) named "e" and
you'll have a conflict.
Click to expand...

You've got a point there.
Thanks for the tip,
Marcel
 
Back
Top