Variables in catch(...) clauses?

  • Thread starter Thread starter Dmitriy Lapshin [C# / .NET MVP]
  • Start date Start date
D

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 said:
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).
Click to expand...

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.)
 
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.
Click to expand...

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).
Click to expand...

Are lots of questions like this in the exams? I mean, do the leave a bit to
my own judgment?
 
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.
 
Me2 said:
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?
Click to expand...

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.
Click to expand...

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.
 
Dmitriy Lapshin [C# / .NET MVP] wrote:

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.
Click to expand...

In that case, how about the following?

try
{
}
catch (SomeException)
{
}

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

<snip>
 
Hi,
In that case, how about the following?

try
{
}
catch (SomeException)
{
}
Click to expand...

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 said:
Dmitriy Lapshin [C# / .NET MVP] wrote:

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.
Click to expand...

In that case, how about the following?

try
{
}
catch (SomeException)
{
}

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

<snip>
Click to expand...
 
Dmitriy said:
Hi,



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.
Click to expand...

Ah, sorry, I misinterpreted your post originally.
 
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 - (e-mail address removed)

Lead Technology Consultant - Flag IntelliWan Brazil
Phone: +55 31 9918-4374, +55 31 3261-6977

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 said:
Hi,
In that case, how about the following?

try
{
}
catch (SomeException)
{
}
Click to expand...

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 said:
Dmitriy Lapshin [C# / .NET MVP] wrote:

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
Click to expand...
Click to expand...
and
so

In that case, how about the following?

try
{
}
catch (SomeException)
{
}

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

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

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
 
Back
Top