Variables in catch(...) clauses?

[Dmitriy Lapshin [C# / .NET MVP]]

Hi all,

When a good developer should declare an exception variable in a catch
clause? Consider an example:

try
{
// Do something potentially dangerous...
}
catch(SomeException e)
{
// Handle the error.
}

My thinking is the "e" variable is only necessary when you need information
about the exception itself, like the error message, the stack trace and so
on. On the other hand, if you only need to do some simple action in the
error handler (say, return a default value), you don't need the "e"
variable - and the compiler would issue the "never used" varning on it if it
is declared.

Still, I have been taking a practice MCP test recently and it claims the
correct option is to always declare the exception variable - without any
reasonable explanation. Well, I fully realize that test authors are humans
who can make mistakes, but is it really a mistake, or I just misunderstand
something or have overlooked some Microsoft guidelines? (the MCP exams are
known to test heavily on anything Microsoft strongly recommends).

--
Dmitriy Lapshin [C# / .NET MVP]
X-Unity Test Studio
http://www.x-unity.net/teststudio.aspx
Bring the power of unit testing to VS .NET IDE

[Jon Skeet [C# MVP]]

Dmitriy Lapshin [C# / .NET MVP] <x-****@no-spam-please.hotpop.com>
wrote:

When a good developer should declare an exception variable in a catch
clause? Consider an example:

try
{
// Do something potentially dangerous...
}
catch(SomeException e)
{
// Handle the error.
}

My thinking is the "e" variable is only necessary when you need information
about the exception itself, like the error message, the stack trace and so
on.
Yes.
On the other hand, if you only need to do some simple action in the
error handler (say, return a default value), you don't need the "e"
variable - and the compiler would issue the "never used" varning on it if it
is declared.
Yes.
Still, I have been taking a practice MCP test recently and it claims the
correct option is to always declare the exception variable - without any
reasonable explanation. Well, I fully realize that test authors are humans
who can make mistakes, but is it really a mistake, or I just misunderstand
something or have overlooked some Microsoft guidelines? (the MCP exams are
known to test heavily on anything Microsoft strongly recommends).

It sounds like they've either made a mistake, or that they believe that
you should *always* be using the actual exception itself - which I
don't personally support. (Often you don't really need to know what the
exception was, just that what you tried to do failed. While it's common
to log the actual cause, it's not always useful.)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Vladimir C.]

"Dmitriy Lapshin [C# / .NET MVP]" <x-****@no-spam-please.hotpop.com> wrote
in message news:uc**************@TK2MSFTNGP10.phx.gbl...

My thinking is the "e" variable is only necessary when you need information about the exception itself, like the error message, the stack trace and so
on. On the other hand, if you only need to do some simple action in the
error handler (say, return a default value), you don't need the "e"
variable - and the compiler would issue the "never used" varning on it if it is declared.
Totally agree with you.
Still, I have been taking a practice MCP test recently and it claims the
correct option is to always declare the exception variable - without any
reasonable explanation. Well, I fully realize that test authors are humans
who can make mistakes, but is it really a mistake, or I just misunderstand
something or have overlooked some Microsoft guidelines? (the MCP exams are
known to test heavily on anything Microsoft strongly recommends).

Are lots of questions like this in the exams? I mean, do the leave a bit to
my own judgment?

[Me2]

I have taken and passed the Web and Windows coding exams and I don't
remember any questions that dealt with whether the exception variable should
or should not be used. I agree with you that if you are not going to
inspect the exception codes that are passed back, then why include the
variable. Would omitting the variable cause the resulting IL code to
execute faster or slower?

As far as having the explicit catch clauses for exceptions, you should have
the catch "all" after the specific tested exceptions in case something bombs
that you did not expect.

--
Ralph Page MBA, CMBA, MCDBA, MCSE, CCNA
-------------------------------------------------------------------------
"However beautiful the strategy, you should occasionally look at the
results."
-- Winston Churchill
-------------------------------------------------------------------------
"Dmitriy Lapshin [C# / .NET MVP]" <x-****@no-spam-please.hotpop.com> wrote
in message news:uc**************@TK2MSFTNGP10.phx.gbl...

Hi all,

When a good developer should declare an exception variable in a catch
clause? Consider an example:

try
{
// Do something potentially dangerous...
}
catch(SomeException e)
{
// Handle the error.
}

My thinking is the "e" variable is only necessary when you need information about the exception itself, like the error message, the stack trace and so
on. On the other hand, if you only need to do some simple action in the
error handler (say, return a default value), you don't need the "e"
variable - and the compiler would issue the "never used" varning on it if it is declared.

Still, I have been taking a practice MCP test recently and it claims the
correct option is to always declare the exception variable - without any
reasonable explanation. Well, I fully realize that test authors are humans
who can make mistakes, but is it really a mistake, or I just misunderstand
something or have overlooked some Microsoft guidelines? (the MCP exams are
known to test heavily on anything Microsoft strongly recommends).

--
Dmitriy Lapshin [C# / .NET MVP]
X-Unity Test Studio
http://www.x-unity.net/teststudio.aspx
Bring the power of unit testing to VS .NET IDE

[Jon Skeet [C# MVP]]

Me2 <[e-mail]> wrote:

I have taken and passed the Web and Windows coding exams and I don't
remember any questions that dealt with whether the exception variable should
or should not be used. I agree with you that if you are not going to
inspect the exception codes that are passed back, then why include the
variable. Would omitting the variable cause the resulting IL code to
execute faster or slower?
The IL generated when there's no variable just pops the exception off
the stack. Basically, I expect there'll be no significant difference in
execution speed.
As far as having the explicit catch clauses for exceptions, you should have
the catch "all" after the specific tested exceptions in case something bombs
that you did not expect.

Only if you actually *want* to catch everything, which you often don't
want to. You may well have a couple of places in the whole code where
you want to catch everything, but many other places where you want to
only catch specific exceptions.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[C# Learner]

Dmitriy Lapshin [C# / .NET MVP] wrote:

<snip>

catch(SomeException e)
{
// Handle the error.
}

My thinking is the "e" variable is only necessary when you need information
about the exception itself, like the error message, the stack trace and so
on. On the other hand, if you only need to do some simple action in the
error handler (say, return a default value), you don't need the "e"
variable - and the compiler would issue the "never used" varning on it if it
is declared.

In that case, how about the following?

try
{
}
catch (SomeException)
{
}

You're still filtering, but there's no need to create the variable.

<snip>

[Dmitriy Lapshin [C# / .NET MVP]]

Hi,

In that case, how about the following?

try
{
}
catch (SomeException)
{
}
This is the option I've actually chosen during the practice exam. It turned
out to be wrong though. Hopefully it is a mistake in the examination
software.

--
Dmitriy Lapshin [C# / .NET MVP]
X-Unity Test Studio
http://www.x-unity.net/teststudio.aspx
Bring the power of unit testing to VS .NET IDE

"C# Learner" <cs****@learner.here> wrote in message
news:O9**************@tk2msftngp13.phx.gbl... Dmitriy Lapshin [C# / .NET MVP] wrote:

<snip>

catch(SomeException e)
{
// Handle the error.
}

My thinking is the "e" variable is only necessary when you need information about the exception itself, like the error message, the stack trace and so on. On the other hand, if you only need to do some simple action in the
error handler (say, return a default value), you don't need the "e"
variable - and the compiler would issue the "never used" varning on it if it is declared.

In that case, how about the following?

try
{
}
catch (SomeException)
{
}

You're still filtering, but there's no need to create the variable.

<snip>

[C# Learner]

Dmitriy Lapshin [C# / .NET MVP] wrote:

Hi,

In that case, how about the following?

try
{
}
catch (SomeException)
{
}

This is the option I've actually chosen during the practice exam. It turned
out to be wrong though. Hopefully it is a mistake in the examination
software.

Ah, sorry, I misinterpreted your post originally.

[Guilherme Magalhaes [MVP]]

If this snip where shown EXACTLY as it is asking if it's necessary or not to
declare e on the exam, I would say that is necessary.

try
{
// Do something potentially dangerous...
}
catch(SomeException e)
{
// Handle the error.
}
However, if the code was this one below, I would say that it's not
necessary.

try
{
// Do something potentially dangerous...
}
catch(SomeException e)
{
// SomeExeption shall be ignored, no more code
return;
}
As I see, the // Handle the error. comment intended to show some work on the
e variable, like new YourException("bla", e);
But I agree with you that the exam should be more precise with this kind of
question. A ideal code snip would be something like this:

try
{
// Do something potentially dangerous...
}
catch(SomeException e)
{
throw new ApplicationException("Something bad hapenned! Run away!", e);
}

That would be cooler :)

[]'s

Guilherme Magalhaes - gu*******@flag.com.br

Lead Technology Consultant - Flag IntelliWan Brazil
Phone: [phone]

MCSD - MCSD for .NET - MCAD - MCDBA - MCT
Macromedia Certified Professional - MMCP
Microsoft Most Valuable Professional - MVP

"Somewhere, something incredible is waiting to be known."
- Carl Sagan

"Dmitriy Lapshin [C# / .NET MVP]" <x-****@no-spam-please.hotpop.com> wrote
in message news:eS*************@TK2MSFTNGP12.phx.gbl...

Hi,

In that case, how about the following?

try
{
}
catch (SomeException)
{
}
This is the option I've actually chosen during the practice exam. It

turned out to be wrong though. Hopefully it is a mistake in the examination
software.

--
Dmitriy Lapshin [C# / .NET MVP]
X-Unity Test Studio
http://www.x-unity.net/teststudio.aspx
Bring the power of unit testing to VS .NET IDE

"C# Learner" <cs****@learner.here> wrote in message
news:O9**************@tk2msftngp13.phx.gbl...

Dmitriy Lapshin [C# / .NET MVP] wrote:

<snip>

catch(SomeException e)
{
// Handle the error.
}

My thinking is the "e" variable is only necessary when you need information about the exception itself, like the error message, the stack trace and

so

on. On the other hand, if you only need to do some simple action in

the error handler (say, return a default value), you don't need the "e"
variable - and the compiler would issue the "never used" varning on it

if it is declared.

In that case, how about the following?

try
{
}
catch (SomeException)
{
}

You're still filtering, but there's no need to create the variable.

<snip>

[The Poster Formerly Known as Kline Sphere]

>

try
{
// Do something potentially dangerous...
}
catch(SomeException e)
{
// SomeExeption shall be ignored, no more code
return;
}

As well as you say, 'ignoring' the exception, there are times when the
mere fact a specific exception has occurred, is all the information
you need to known in order to perform processing based on the type of
exception; thus ignoring the content of the exception itself.

In any case, as has already been said, the 'solution' depends on the
individual circumstances of the algorithm. Thus, any question would
need to describe the purpose of the algorithm before a 'correct'
answer can be given.

Kline Sphere (Chalk) MCNGP #3