Re: Ignoring excpetions in catch
On 2 June 2010 14:16, Nick Wienholt li...@dotnetperformance.com wrote:
Hi Mike,
Fatal exceptions: you might want to do something like write out a
.dmp file before you put the process out of its misery
I'd probably prefer to leave this to a tool like ADPlus rather than have
application code (particularly managed application code) do it. There
doesn't seem much advantage of trying to capture the information from a
process in a state of distress.
I've found Adplus to be completely useless, compared to this
technique. I get dmp files of the code when it's running perfectly
(from customer submitted dmp files from ADPlus), rather than a dmp
file that shows where it has failed. You don't need to tell a
customer what to do, just get them to send the dmp file/s. You simply
need to be disciplined about what you call from inside the code that
is generating the file. (and that probably does make it hard for
dotnet code(but this is done in a c++ codebase), but it also includes
not calling a lot of the CRT) Even if you do get the customer to use
ADplus correctly, the error might not show up for another 6 months or
so.
Nick
-Original Message-
From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On
Behalf Of mike smith
Sent: Wednesday, 2 June 2010 1:14 PM
To: ozDotNet
Subject: Re: Ignoring excpetions in catch
On 1 June 2010 18:37, James Chapman-Smith ja...@enigmativity.com wrote:
Handling exceptions requires exceptional programming - literally
figuratively.
I find that there are very few times that you actually need to handle
exceptions. Very few.
Rampant exceptional handling creates more nightmares than it solves. It
makes debugging almost impossible as your code stops at the wrong lines in
the wrong classes in the wrong projects.
No, my friends, exception handling is generally poorly handled by all but
the most experienced developers.
Have a read of this article from Eric Lippert -
http://blogs.msdn.com/b/ericlippert/archive/2008/09/10/vexing-exceptions.asp
x - he sums it up nicely I think.
Fatal exceptions: you might want to do something like write out a
.dmp file before you put the process out of its misery. That'd
normally be SEH, and there are nicer ways of doing it now.
:-)
James.
-Original Message-
From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
On Behalf Of Arjang Assadi
Sent: Tuesday, 1 June 2010 10:09
To: ozDotNet
Subject: Ignoring excpetions in catch
I thought only the beginner programmers or programmers without any
pride in their work or self discipline would write code like this:
try
{
//some code goes here
}
catch
{
//No code here just business as usual, do nothing about the exceptions!
}
but maybe I am wrong, this http://support.microsoft.com/kb/319465 was
unexpected!
in the code in the above link are there any reasons for
1)Checking the type, or more generally first checking that at least
the minimum requirements of an operations will be satisfied before
using a sledge hammer?
2)Using some other (better) code e.g. reflection etc. would be
definitely more preferable to ignoring excpetion?
3)Any other suggestions?
Regards
Arjang
--
Meski
Going to Starbucks for coffee is like going to prison for sex. Sure,
you'll get it, but it's going to be rough - Adam Hills
--
Meski
Going to Starbucks for coffee is like going to prison for sex. Sure,
you'll get it, but it's going to be rough - Adam Hills
RE: Ignoring excpetions in catch
Handling exceptions requires exceptional programming - literally
figuratively.
I find that there are very few times that you actually need to handle
exceptions. Very few.
Rampant exceptional handling creates more nightmares than it solves. It
makes debugging almost impossible as your code stops at the wrong lines in
the wrong classes in the wrong projects.
No, my friends, exception handling is generally poorly handled by all but
the most experienced developers.
Have a read of this article from Eric Lippert -
http://blogs.msdn.com/b/ericlippert/archive/2008/09/10/vexing-exceptions.asp
x - he sums it up nicely I think.
:-)
James.
-Original Message-
From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
On Behalf Of Arjang Assadi
Sent: Tuesday, 1 June 2010 10:09
To: ozDotNet
Subject: Ignoring excpetions in catch
I thought only the beginner programmers or programmers without any
pride in their work or self discipline would write code like this:
try
{
//some code goes here
}
catch
{
//No code here just business as usual, do nothing about the exceptions!
}
but maybe I am wrong, this http://support.microsoft.com/kb/319465 was
unexpected!
in the code in the above link are there any reasons for
1)Checking the type, or more generally first checking that at least
the minimum requirements of an operations will be satisfied before
using a sledge hammer?
2)Using some other (better) code e.g. reflection etc. would be
definitely more preferable to ignoring excpetion?
3)Any other suggestions?
Regards
Arjang
RE: Ignoring excpetions in catch
Hi Matt,
Text wrapping got the best of you I suspect ... The 'x' from the .aspx
extension was wrapped onto the next line of the message.
Cheers,
Trevor
-Original Message-
From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
On Behalf Of Matt
Sent: Wednesday, 2 June 2010 10:50 AM
To: ozDotNet
Subject: Re: Ignoring excpetions in catch
LOL, when I tried that link, I got an exception(404) AND IT WASN'T
HANDLED, ROFL.
I guess that's your point!
Regards,
Matt
--
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it. Brian W. Kernighan
James Chapman-Smith wrote:
Handling exceptions requires exceptional programming - literally
figuratively.
I find that there are very few times that you actually need to handle
exceptions. Very few.
Rampant exceptional handling creates more nightmares than it solves. It
makes debugging almost impossible as your code stops at the wrong lines in
the wrong classes in the wrong projects.
No, my friends, exception handling is generally poorly handled by all but
the most experienced developers.
Have a read of this article from Eric Lippert -
http://blogs.msdn.com/b/ericlippert/archive/2008/09/10/vexing-exceptions.asp
x - he sums it up nicely I think.
:-)
James.
-Original Message-
From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
On Behalf Of Arjang Assadi
Sent: Tuesday, 1 June 2010 10:09
To: ozDotNet
Subject: Ignoring excpetions in catch
I thought only the beginner programmers or programmers without any
pride in their work or self discipline would write code like this:
try
{
//some code goes here
}
catch
{
//No code here just business as usual, do nothing about the exceptions!
}
but maybe I am wrong, this http://support.microsoft.com/kb/319465 was
unexpected!
in the code in the above link are there any reasons for
1)Checking the type, or more generally first checking that at least
the minimum requirements of an operations will be satisfied before
using a sledge hammer?
2)Using some other (better) code e.g. reflection etc. would be
definitely more preferable to ignoring excpetion?
3)Any other suggestions?
Regards
Arjang
Re: Ignoring excpetions in catch
On 1 June 2010 18:37, James Chapman-Smith ja...@enigmativity.com wrote:
Handling exceptions requires exceptional programming - literally
figuratively.
I find that there are very few times that you actually need to handle
exceptions. Very few.
Rampant exceptional handling creates more nightmares than it solves. It
makes debugging almost impossible as your code stops at the wrong lines in
the wrong classes in the wrong projects.
No, my friends, exception handling is generally poorly handled by all but
the most experienced developers.
Have a read of this article from Eric Lippert -
http://blogs.msdn.com/b/ericlippert/archive/2008/09/10/vexing-exceptions.asp
x - he sums it up nicely I think.
Fatal exceptions: you might want to do something like write out a
.dmp file before you put the process out of its misery. That'd
normally be SEH, and there are nicer ways of doing it now.
:-)
James.
-Original Message-
From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
On Behalf Of Arjang Assadi
Sent: Tuesday, 1 June 2010 10:09
To: ozDotNet
Subject: Ignoring excpetions in catch
I thought only the beginner programmers or programmers without any
pride in their work or self discipline would write code like this:
try
{
//some code goes here
}
catch
{
//No code here just business as usual, do nothing about the exceptions!
}
but maybe I am wrong, this http://support.microsoft.com/kb/319465 was
unexpected!
in the code in the above link are there any reasons for
1)Checking the type, or more generally first checking that at least
the minimum requirements of an operations will be satisfied before
using a sledge hammer?
2)Using some other (better) code e.g. reflection etc. would be
definitely more preferable to ignoring excpetion?
3)Any other suggestions?
Regards
Arjang
--
Meski
Going to Starbucks for coffee is like going to prison for sex. Sure,
you'll get it, but it's going to be rough - Adam Hills
Ignoring excpetions in catch
I thought only the beginner programmers or programmers without any
pride in their work or self discipline would write code like this:
try
{
//some code goes here
}
catch
{
//No code here just business as usual, do nothing about the exceptions!
}
but maybe I am wrong, this http://support.microsoft.com/kb/319465 was
unexpected!
in the code in the above link are there any reasons for
1)Checking the type, or more generally first checking that at least
the minimum requirements of an operations will be satisfied before
using a sledge hammer?
2)Using some other (better) code e.g. reflection etc. would be
definitely more preferable to ignoring excpetion?
3)Any other suggestions?
Regards
Arjang
Re: Ignoring excpetions in catch
Yep, just change the cast from:
ctlMDI = (MdiClient) ctl;
to
ctlMDI = ctl as MdiClient;
then check for null.
But having said that, I'm sure all of the code on MSDN/Microsoft web sites
are not production ready.. The code is only to communicate ideas..
Just my 2c...
Ed.
On Tue, Jun 1, 2010 at 10:38 AM, Arjang Assadi arjang.ass...@gmail.comwrote:
I thought only the beginner programmers or programmers without any
pride in their work or self discipline would write code like this:
try
{
//some code goes here
}
catch
{
//No code here just business as usual, do nothing about the exceptions!
}
but maybe I am wrong, this http://support.microsoft.com/kb/319465 was
unexpected!
in the code in the above link are there any reasons for
1)Checking the type, or more generally first checking that at least
the minimum requirements of an operations will be satisfied before
using a sledge hammer?
2)Using some other (better) code e.g. reflection etc. would be
definitely more preferable to ignoring excpetion?
3)Any other suggestions?
Regards
Arjang
--
Eddie de Bear
Mob: 0417066315
Messenger: eddie_deb...@hotmail.com
Skype: eddiedebear
Re: Ignoring excpetions in catch
Your example is a catch all which is bad practice.
The example in the MS article catches a specific exception. This is not the
same thing. There can be circumstances where you want to catch a specific
exception and do nothing about it.
On 1 June 2010 10:38, Arjang Assadi arjang.ass...@gmail.com wrote:
I thought only the beginner programmers or programmers without any
pride in their work or self discipline would write code like this:
try
{
//some code goes here
}
catch
{
//No code here just business as usual, do nothing about the exceptions!
}
but maybe I am wrong, this http://support.microsoft.com/kb/319465 was
unexpected!
in the code in the above link are there any reasons for
1)Checking the type, or more generally first checking that at least
the minimum requirements of an operations will be satisfied before
using a sledge hammer?
2)Using some other (better) code e.g. reflection etc. would be
definitely more preferable to ignoring excpetion?
3)Any other suggestions?
Regards
Arjang
RE: Ignoring excpetions in catch
Hi Arjang,
In C# use the as operator and check for null; in VB use TryCast and check
for Nothing.
|-Original Message-
|From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-
|boun...@ozdotnet.com] On Behalf Of Arjang Assadi
|Sent: Tuesday, 1 June 2010 10:39 AM
|To: ozDotNet
|Subject: Ignoring excpetions in catch
|
|I thought only the beginner programmers or programmers without any
|pride in their work or self discipline would write code like this:
|
|try
|{
| //some code goes here
|}
|catch
|{
| //No code here just business as usual, do nothing about the exceptions!
|}
|
|but maybe I am wrong, this http://support.microsoft.com/kb/319465 was
|unexpected!
|in the code in the above link are there any reasons for
|1)Checking the type, or more generally first checking that at least
|the minimum requirements of an operations will be satisfied before
|using a sledge hammer?
|
|2)Using some other (better) code e.g. reflection etc. would be
|definitely more preferable to ignoring excpetion?
|
|3)Any other suggestions?
|
|Regards
|
|Arjang
Re: Ignoring excpetions in catch
Agreed, e.g. using 3rd party controls where one is at the mercy of
what ever is given is the only circumstance that comes to my mind. is
there any other circumstance that one would want to do nothing about
the exception and fix the cause rather than ignore the symptom?
Kind Regards
Arjang
On 1 June 2010 10:48, Grant Maw grant@gmail.com wrote:
Your example is a catch all which is bad practice.
The example in the MS article catches a specific exception. This is not the
same thing. There can be circumstances where you want to catch a specific
exception and do nothing about it.
On 1 June 2010 10:38, Arjang Assadi arjang.ass...@gmail.com wrote:
I thought only the beginner programmers or programmers without any
pride in their work or self discipline would write code like this:
try
{
//some code goes here
}
catch
{
//No code here just business as usual, do nothing about the exceptions!
}
but maybe I am wrong, this http://support.microsoft.com/kb/319465 was
unexpected!
in the code in the above link are there any reasons for
1)Checking the type, or more generally first checking that at least
the minimum requirements of an operations will be satisfied before
using a sledge hammer?
2)Using some other (better) code e.g. reflection etc. would be
definitely more preferable to ignoring excpetion?
3)Any other suggestions?
Regards
Arjang
Re: Ignoring excpetions in catch
Hi Bill,
Thank you for your reply. I knew that, but the question is the
practice of ignoring excpetions in catch.
Using is and as is 1% improvement over a ignoring the
exception in that example by any means, that was also suggested by
Eddie. But why or when would one ignore the specific exception when it
could have been preventet and ignore it instead?
Regards
Arjang
On 1 June 2010 10:58, Bill McCarthy b...@totalenviro.com wrote:
Hi Arjang,
In C# use the as operator and check for null; in VB use TryCast and check
for Nothing.
|-Original Message-
|From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-
|boun...@ozdotnet.com] On Behalf Of Arjang Assadi
|Sent: Tuesday, 1 June 2010 10:39 AM
|To: ozDotNet
|Subject: Ignoring excpetions in catch
|
|I thought only the beginner programmers or programmers without any
|pride in their work or self discipline would write code like this:
|
|try
|{
| //some code goes here
|}
|catch
|{
| //No code here just business as usual, do nothing about the exceptions!
|}
|
|but maybe I am wrong, this http://support.microsoft.com/kb/319465 was
|unexpected!
|in the code in the above link are there any reasons for
|1)Checking the type, or more generally first checking that at least
|the minimum requirements of an operations will be satisfied before
|using a sledge hammer?
|
|2)Using some other (better) code e.g. reflection etc. would be
|definitely more preferable to ignoring excpetion?
|
|3)Any other suggestions?
|
|Regards
|
|Arjang
RE: Ignoring excpetions in catch
I wouldn't take that sample code seriously, I guess it's old. As the others
said, in that case a cast as or try would be more appropriate. The Framework
Design Guidelines http://msdn.microsoft.com/en-us/library/ms229042.aspx
(BOOK
http://www.amazon.com/Framework-Design-Guidelines-Conventions-Libraries/dp/
0321246756 ) covers all of these sorts of issues nicely, especially about
what is exceptional or not, and that sample is not exceptional.
A ramble for newer coders here ... I fell for the trap in the my earlier
.NET coding years of over-catching. I think a lot of people had to get out
of the habit of swallowing exceptions. I've recently been working on app
code I wrote over the last several years, and I have been slowly removing
hundreds and hundreds of lines of try-catch blocks. I can see now that most
of them do nothing but clutter up the code. In my old UI code I keep finding
stuff like this skeleton:
try
{
dataSource = DataLayer.GetSomething();
}
Catch (Exception ex)
{
MessageBox.Show(Something rotten happened. + ex.ToString());
}
It's completely useless, as the method call is not supposed to fail, and if
it does fail then something is so very stuffed up that the app should crash
and stop anyway. I remove all the obviously useless try-catch blocks as I
go.
You should never try-catch unless you know specifically what you're going to
catch and you know what to do with it.
Greg
Ps. Thanks for the replies about source control of DB scripts. We'll be
discussing this over the coming days.
