Hi all,
When a good developer should declare an exception variable in a catch
clause? Consider an example:
try
{
// Do something potentially dangerous...
}
catch(SomeExcep tion 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 9 1767
Dmitriy Lapshin [C# / .NET MVP] <x-****@no-spam-please.hotpop.c om>
wrote: When a good developer should declare an exception variable in a catch clause? Consider an example:
try { // Do something potentially dangerous... } catch(SomeExcep tion 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.co m> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
"Dmitriy Lapshin [C# / .NET MVP]" <x-****@no-spam-please.hotpop.c om> wrote
in message news:uc******** ******@TK2MSFTN GP10.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?
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.c om> wrote
in message news:uc******** ******@TK2MSFTN GP10.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(SomeExcep tion 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
Me2 <r@r.com> 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.co m> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Dmitriy Lapshin [C# / .NET MVP] wrote:
<snip> catch(SomeExcep tion 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>
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******** ******@tk2msftn gp13.phx.gbl... Dmitriy Lapshin [C# / .NET MVP] wrote:
<snip>
catch(SomeExcep tion 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] 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.
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(SomeExcep tion 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(SomeExcep tion 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(SomeExcep tion e)
{
throw new ApplicationExce ption("Somethin g bad hapenned! Run away!", e);
}
That would be cooler :)
[]'s
Guilherme Magalhaes - gu*******@flag. com.br
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 [C# / .NET MVP]" <x-****@no-spam-please.hotpop.c om> wrote
in message news:eS******** *****@TK2MSFTNG P12.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******** ******@tk2msftn gp13.phx.gbl... Dmitriy Lapshin [C# / .NET MVP] wrote:
<snip>
catch(SomeExcep tion 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>
> try { // Do something potentially dangerous... } catch(SomeExce ption 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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics |
by: Steven T. Hatton |
last post by:
If I understand correctly, I have no assurance that I can determine the type
of a simple class instance thrown as an exception unless I explicitly catch
it by name. (non-derived classes having no virtual funcitons have no rtti)
That is, there is no way to do something like:
try{
funct_from_3rd_party();
}
catch(...){
std:err << extract_name() << std::endl;
}
|
by: White Wolf |
last post by:
Hi,
I cannot believe my eyes, but so far I could not find out what is the name
of the construct, which is built from one try block and the catch clauses
(handlers). I am not looking for a grammar name, but something people can
remember, like handler. But is not handler, because those are the catch
clauses and the try does not belong there. I have looked at all my books
and the standard, but I could not find a name. :-(
Is there...
|
by: Khuong Dinh Pham |
last post by:
How can i get more information about the exception when using catch(...)?
Thx in advance
|
by: Steve |
last post by:
I have some general catch clauses in my app as follows:
try
{
}
catch(Exception ex)
{
}
try
|
by: Steve Murphy |
last post by:
I have a couple of standard Try/Catch blocks that I use repeatedly. Is there
anyway to wrap these blocks into a method call? Or does C# have anything like a
C++ macro?
Thanks,
Steve Murphy
| |
by: cj |
last post by:
Another wish of mine. I wish there was a way in the Try Catch structure
to say if there wasn't an error to do something. Like an else
statement. Try Catch Else Finally.
Also because I understand Finally runs whether an error was caught or
not, I haven't found a use for finally yet.
|
by: Noah Roberts |
last post by:
The following code does VERY strange things in the debugger. Is there
anything wrong with the following code, UB or anything else?
#include <iostream>
#include <exception>
#include <stdexcept>
int main()
{
int * parser;
|
by: reycri |
last post by:
While the following is allowed:
if (a == b)
SomeFunction();
else
OtherFunction();
The following is not:
try
|
by: Nick Keighley |
last post by:
Hi,
I know in principal this is unanswerable as it is be implementation
dependent.I have a code base that is heavily littered with try/catch
clauses (the CASE tool has been set up to put a try/catch round
every member function).
Now I know this is BAD but I just wondered how bad. Will it kill
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it.
First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it.
Here is my compilation command:
g++-12 -std=c++20 -Wnarrowing bit_field.cpp
Here is the code in...
| |
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own....
Now, this would greatly impact the work of software developers. The idea...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules.
He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms.
Adolph will...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols.
I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| |
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...
| |