Hi.
I have read several articles recommending avoid to raise exceptions when
possible, since exceptions are expensive to the system. Removing code from
Try... Catch blocks can help performance? The following 2 first lines of
code - I think - can't raise exceptions:
Try
Dim str As String
Dim intVar As Integer
'More code here
Catch Ex As Exception
End Try
Should I remove the variable declarations from the Try block or doing that
won't help me at all?
TIA,
Erik Cruz 6 2981
No. The expensive thing is raising an exception. While an exception is
not raised, there is not performance penalty. (at least not
considerably)
On Sat, 18 Oct 2003 17:02:03 -0300, "Erik Cruz"
<er************ ******@antares. com.br> wrote: Hi.
I have read several articles recommending avoid to raise exceptions when possible, since exceptions are expensive to the system. Removing code from Try... Catch blocks can help performance? The following 2 first lines of code - I think - can't raise exceptions:
Try Dim str As String Dim intVar As Integer 'More code here
Catch Ex As Exception
End Try
Should I remove the variable declarations from the Try block or doing that won't help me at all?
TIA, Erik Cruz
Try...Catch is only needed around code that could throw an exception. So,
if you have lots of code that does very simple work, but only one line that
could throw an exception, you normally would just wrap the one line in the
exception and catch only the exception that you are concerned with.
Exceptions are expensive when thrown, but only when thrown. That is the key
point. Simply having code within a try block does not necessarily make your
code run slower. If you wrap code that never throws an exception in a try
block, it will run just as fast as if there was no try block.
Also, unless you have reason to, you might want to limit your catch
statement to specific exceptions. Catching the base Exception is usually
not done and offers little help when analyzing what happened.
"Erik Cruz" <er************ ******@antares. com.br> wrote in message
news:#c******** ******@TK2MSFTN GP11.phx.gbl... Hi.
I have read several articles recommending avoid to raise exceptions when possible, since exceptions are expensive to the system. Removing code from Try... Catch blocks can help performance? The following 2 first lines of code - I think - can't raise exceptions:
Try Dim str As String Dim intVar As Integer 'More code here
Catch Ex As Exception
End Try
Should I remove the variable declarations from the Try block or doing that won't help me at all?
TIA, Erik Cruz
Those two declarations don't do anything, so they can't throw an
exception..henc e no need to wrap them in the try catch block. I haven't
looked at the IL, but I don't believe variable declaration are treated the
same..but I'm not sure, I'll have to get back to you.
In addition to performance, there are good reasons to only trap small bits
of code and in most instances, don't trap System.Exceptio n except in
instances where you know you want to do so. If you had an OutOfMemory
Exception raised in that block, your routine would catch it. However, there
isn't much you are going to do programatically about this problem, and you
want to use exception handlers to respond to things are try to elegantly
recover. In general wrap risky code blocks,like Opening Database
connections or filestreams, where things beyond your code logic can cause
problems. There are other instances where things are very unlikely to occur
if you are careful coding like getting an OutOfRange exception in a loop.
If you carefully and liberally use Assertions in your test environment, you
can responsibly conclude that your code won't throw certain types of
exceptions, but this approach is not to say that you don't want to use
handlers at all.
In VB6 there was this ghastly construct called OnError Resume, and there
were a lot of progrrammers that thought this was all you need for exception
handling. In .NET, such a constrcut will work in VB.NET, but what it does
is wrap every single line of code in the block in it's own try catch
statement. This is awful for performance (not to mention that it can/does
cover up coding flaws). Most articles that I've read about not throwing
unneeded exceptions relate to people carelessly throwing out try catch
blocks, or intentionally raising an exception when an event would be much
more appropriate. For instance, in a BankAccount Class, if the user deducts
more than is avaialable, you could have a OverDrawn event that simply tells
the user this transaction won't work b/c the money isn't there. This is
pretty straightforward OO approach to such a problem. On the other hand,
you could throw a custom exception NotEnoughMoneyE xception. The problem
with the second approach is that A) You'd need to wrap your deposit function
with a try Catch to catch this, and that this isn't really an exception from
the compiler's point of view.
There are instances where you can just eat an exception, and it's ok to do
so. After all, the whole purpose of structured exceptions is to Handle
problems that you know can come up, and you can't necessarily preepmt with
your code.
If you follow John Robbins (the MSDN BugSlayer - buy his book if you don't
have it already), or Jeffrey Richter to use just two examples, they seldom
have more than a line of code wrapped in a try catch block. At most you
might see three or four but that is rare. Very precise, very targeted.
That is usually what most articles are advocating when they mention this.
HTH,
Bill
"Erik Cruz" <er************ ******@antares. com.br> wrote in message
news:%2******** ********@TK2MSF TNGP11.phx.gbl. .. Hi.
I have read several articles recommending avoid to raise exceptions when possible, since exceptions are expensive to the system. Removing code from Try... Catch blocks can help performance? The following 2 first lines of code - I think - can't raise exceptions:
Try Dim str As String Dim intVar As Integer 'More code here
Catch Ex As Exception
End Try
Should I remove the variable declarations from the Try block or doing that won't help me at all?
TIA, Erik Cruz
> looked at the IL, but I don't believe variable declaration are treated the same..but I'm not sure, I'll have to get back to you.
This is probably not a realistic case, but will throw an exception ......
Dim a As Int32
a = 45000
Dim b As Int16 = a
Bob Lehmann
"William Ryan" <do********@com cast.nospam.net > wrote in message
news:OO******** ******@TK2MSFTN GP12.phx.gbl... Those two declarations don't do anything, so they can't throw an exception..henc e no need to wrap them in the try catch block. I haven't looked at the IL, but I don't believe variable declaration are treated the same..but I'm not sure, I'll have to get back to you.
In addition to performance, there are good reasons to only trap small bits of code and in most instances, don't trap System.Exceptio n except in instances where you know you want to do so. If you had an OutOfMemory Exception raised in that block, your routine would catch it. However,
there isn't much you are going to do programatically about this problem, and you want to use exception handlers to respond to things are try to elegantly recover. In general wrap risky code blocks,like Opening Database connections or filestreams, where things beyond your code logic can cause problems. There are other instances where things are very unlikely to
occur if you are careful coding like getting an OutOfRange exception in a loop. If you carefully and liberally use Assertions in your test environment,
you can responsibly conclude that your code won't throw certain types of exceptions, but this approach is not to say that you don't want to use handlers at all.
In VB6 there was this ghastly construct called OnError Resume, and there were a lot of progrrammers that thought this was all you need for
exception handling. In .NET, such a constrcut will work in VB.NET, but what it does is wrap every single line of code in the block in it's own try catch statement. This is awful for performance (not to mention that it can/does cover up coding flaws). Most articles that I've read about not throwing unneeded exceptions relate to people carelessly throwing out try catch blocks, or intentionally raising an exception when an event would be much more appropriate. For instance, in a BankAccount Class, if the user
deducts more than is avaialable, you could have a OverDrawn event that simply
tells the user this transaction won't work b/c the money isn't there. This is pretty straightforward OO approach to such a problem. On the other hand, you could throw a custom exception NotEnoughMoneyE xception. The problem with the second approach is that A) You'd need to wrap your deposit
function with a try Catch to catch this, and that this isn't really an exception
from the compiler's point of view.
There are instances where you can just eat an exception, and it's ok to do so. After all, the whole purpose of structured exceptions is to Handle problems that you know can come up, and you can't necessarily preepmt with your code.
If you follow John Robbins (the MSDN BugSlayer - buy his book if you don't have it already), or Jeffrey Richter to use just two examples, they seldom have more than a line of code wrapped in a try catch block. At most you might see three or four but that is rare. Very precise, very targeted. That is usually what most articles are advocating when they mention this.
HTH,
Bill "Erik Cruz" <er************ ******@antares. com.br> wrote in message news:%2******** ********@TK2MSF TNGP11.phx.gbl. .. Hi.
I have read several articles recommending avoid to raise exceptions when possible, since exceptions are expensive to the system. Removing code
from Try... Catch blocks can help performance? The following 2 first lines of code - I think - can't raise exceptions:
Try Dim str As String Dim intVar As Integer 'More code here
Catch Ex As Exception
End Try
Should I remove the variable declarations from the Try block or doing
that won't help me at all?
TIA, Erik Cruz
Point taken, I should have been more clear. An initialization coupled with
a Declaration could possibly throw an exception, but I don't think a simple
declaration could.
"Bob Lehmann" <no****@dontbot herme.zzz> wrote in message
news:%2******** ********@tk2msf tngp13.phx.gbl. .. looked at the IL, but I don't believe variable declaration are treated
the same..but I'm not sure, I'll have to get back to you.
This is probably not a realistic case, but will throw an exception ......
Dim a As Int32 a = 45000
Dim b As Int16 = a
Bob Lehmann
"William Ryan" <do********@com cast.nospam.net > wrote in message news:OO******** ******@TK2MSFTN GP12.phx.gbl... Those two declarations don't do anything, so they can't throw an exception..henc e no need to wrap them in the try catch block. I haven't looked at the IL, but I don't believe variable declaration are treated
the same..but I'm not sure, I'll have to get back to you.
In addition to performance, there are good reasons to only trap small
bits of code and in most instances, don't trap System.Exceptio n except in instances where you know you want to do so. If you had an OutOfMemory Exception raised in that block, your routine would catch it. However, there isn't much you are going to do programatically about this problem, and
you want to use exception handlers to respond to things are try to elegantly recover. In general wrap risky code blocks,like Opening Database connections or filestreams, where things beyond your code logic can
cause problems. There are other instances where things are very unlikely to occur if you are careful coding like getting an OutOfRange exception in a
loop. If you carefully and liberally use Assertions in your test environment, you can responsibly conclude that your code won't throw certain types of exceptions, but this approach is not to say that you don't want to use handlers at all.
In VB6 there was this ghastly construct called OnError Resume, and there were a lot of progrrammers that thought this was all you need for exception handling. In .NET, such a constrcut will work in VB.NET, but what it
does is wrap every single line of code in the block in it's own try catch statement. This is awful for performance (not to mention that it
can/does cover up coding flaws). Most articles that I've read about not throwing unneeded exceptions relate to people carelessly throwing out try catch blocks, or intentionally raising an exception when an event would be
much more appropriate. For instance, in a BankAccount Class, if the user deducts more than is avaialable, you could have a OverDrawn event that simply tells the user this transaction won't work b/c the money isn't there. This is pretty straightforward OO approach to such a problem. On the other
hand, you could throw a custom exception NotEnoughMoneyE xception. The problem with the second approach is that A) You'd need to wrap your deposit function with a try Catch to catch this, and that this isn't really an exception from the compiler's point of view.
There are instances where you can just eat an exception, and it's ok to
do so. After all, the whole purpose of structured exceptions is to Handle problems that you know can come up, and you can't necessarily preepmt
with your code.
If you follow John Robbins (the MSDN BugSlayer - buy his book if you
don't have it already), or Jeffrey Richter to use just two examples, they
seldom have more than a line of code wrapped in a try catch block. At most you might see three or four but that is rare. Very precise, very targeted. That is usually what most articles are advocating when they mention
this. HTH,
Bill "Erik Cruz" <er************ ******@antares. com.br> wrote in message news:%2******** ********@TK2MSF TNGP11.phx.gbl. .. Hi.
I have read several articles recommending avoid to raise exceptions
when possible, since exceptions are expensive to the system. Removing code from Try... Catch blocks can help performance? The following 2 first lines
of code - I think - can't raise exceptions:
Try Dim str As String Dim intVar As Integer 'More code here
Catch Ex As Exception
End Try
Should I remove the variable declarations from the Try block or doing that won't help me at all?
TIA, Erik Cruz
All declarations will be for the method in the IL anyways. A declaration
doesn't do anything except make IL emit the .locals(whateve r, whatever,
etc.).
-mike
MVP
"William Ryan" <do********@nos pam.comcast.net > wrote in message
news:uo******** ******@TK2MSFTN GP11.phx.gbl... Point taken, I should have been more clear. An initialization coupled
with a Declaration could possibly throw an exception, but I don't think a
simple declaration could. "Bob Lehmann" <no****@dontbot herme.zzz> wrote in message news:%2******** ********@tk2msf tngp13.phx.gbl. .. looked at the IL, but I don't believe variable declaration are treated the same..but I'm not sure, I'll have to get back to you. This is probably not a realistic case, but will throw an exception
....... Dim a As Int32 a = 45000
Dim b As Int16 = a
Bob Lehmann
"William Ryan" <do********@com cast.nospam.net > wrote in message news:OO******** ******@TK2MSFTN GP12.phx.gbl... Those two declarations don't do anything, so they can't throw an exception..henc e no need to wrap them in the try catch block. I
haven't looked at the IL, but I don't believe variable declaration are treated the same..but I'm not sure, I'll have to get back to you.
In addition to performance, there are good reasons to only trap small bits of code and in most instances, don't trap System.Exceptio n except in instances where you know you want to do so. If you had an OutOfMemory Exception raised in that block, your routine would catch it. However, there isn't much you are going to do programatically about this problem, and you want to use exception handlers to respond to things are try to
elegantly recover. In general wrap risky code blocks,like Opening Database connections or filestreams, where things beyond your code logic can cause problems. There are other instances where things are very unlikely to
occur if you are careful coding like getting an OutOfRange exception in a loop. If you carefully and liberally use Assertions in your test
environment, you can responsibly conclude that your code won't throw certain types of exceptions, but this approach is not to say that you don't want to use handlers at all.
In VB6 there was this ghastly construct called OnError Resume, and
there were a lot of progrrammers that thought this was all you need for exception handling. In .NET, such a constrcut will work in VB.NET, but what it
does is wrap every single line of code in the block in it's own try catch statement. This is awful for performance (not to mention that it can/does cover up coding flaws). Most articles that I've read about not
throwing unneeded exceptions relate to people carelessly throwing out try catch blocks, or intentionally raising an exception when an event would be much more appropriate. For instance, in a BankAccount Class, if the user deducts more than is avaialable, you could have a OverDrawn event that simply tells the user this transaction won't work b/c the money isn't there. This
is pretty straightforward OO approach to such a problem. On the other hand, you could throw a custom exception NotEnoughMoneyE xception. The
problem with the second approach is that A) You'd need to wrap your deposit function with a try Catch to catch this, and that this isn't really an
exception from the compiler's point of view.
There are instances where you can just eat an exception, and it's ok
to do so. After all, the whole purpose of structured exceptions is to
Handle problems that you know can come up, and you can't necessarily preepmt with your code.
If you follow John Robbins (the MSDN BugSlayer - buy his book if you don't have it already), or Jeffrey Richter to use just two examples, they seldom have more than a line of code wrapped in a try catch block. At most
you might see three or four but that is rare. Very precise, very
targeted. That is usually what most articles are advocating when they mention this. HTH,
Bill "Erik Cruz" <er************ ******@antares. com.br> wrote in message news:%2******** ********@TK2MSF TNGP11.phx.gbl. .. > Hi. > > I have read several articles recommending avoid to raise exceptions when > possible, since exceptions are expensive to the system. Removing
code from > Try... Catch blocks can help performance? The following 2 first
lines of > code - I think - can't raise exceptions: > > Try > Dim str As String > Dim intVar As Integer > 'More code here > > Catch Ex As Exception > > End Try > > Should I remove the variable declarations from the Try block or
doing that > won't help me at all? > > TIA, > Erik Cruz > >
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics |
by: Erik Cruz |
last post by:
Hi.
I have read several articles recommending avoid to raise exceptions when
possible, since exceptions are expensive to the system. Removing code from
Try... Catch blocks can help performance? The following 2 first lines of
code - I think - can't raise exceptions:
Try
Dim str As String
Dim intVar As Integer
|
by: Pohihihi |
last post by:
I was wondering what is the ill effect of using try catch in the code, both
nested and simple big one.
e.g.
try
{
\\ whole app code goes here
} catch (Exception ee) {}
|
by: BC |
last post by:
Hi all,
I have a method that accepts a string as the parameter. This can be a
base64 image string, or just a normal string. Currently to test whether
it's a image string or just a normal string, I used try and catch:
private void MyMethod(string str){
try{
// If not exception is cought, then it is an image string
MemoryStream stream = new MemoryStream(Convert.FromBase64String(str));
|
by: clintonG |
last post by:
Has somebody written any guidelines regarding how to determine when
try-catch blocks should be used and where their use would or could be
considered superfluous?
<%= Clinton Gallagher
METROmilwaukee (sm) "A Regional Information Service"
NET csgallagher AT metromilwaukee.com
URL http://metromilwaukee.com/
URL http://clintongallagher.metromilwaukee.com/
|
by: STom |
last post by:
I heard someone mention to me that the use of try catch exception handling
is very expensive (in relative terms of slowing an app down) if it is used
frequently. Of course they could not explain why.
Is this true? If so, why?
Thanks.
STom
| |
by: Tiraman |
last post by:
Hi ,
I am using allot the try catch in my code and the question is
if it is good ?
it will decrease my performance ?
one more question
|
by: Michael MacDonald |
last post by:
Does someone have a good site I can visit or explain the use of Try" and
Catch foe exception/error handling. What is the logic behind this
command and maybe an example would be great!!!!
Mike_Mac
*** Sent via Devdex http://www.devdex.com ***
Don't just participate in USENET...get rewarded for it!
|
by: tshad |
last post by:
Normally, I surround my Dataset/fill or DBreader execut with a try/Catch.
Something like:
******************************************************
Dim dbReader As SqlDataReader
Dim ConnectionString as String
=System.Configuration.ConfigurationSettings.AppSettings("MM_CONNECTION_STRING_Connection")
Dim objConn as New SqlConnection (ConnectionString)
Dim CommandText as String = "Select City,StateCode from zipCodes where
|
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: =?Utf-8?B?TWlrZQ==?= |
last post by:
Hi. I have a class with an collection property. The collection property is
sometimes equal to nothing. The class has a function named 'Exists' which
returns TRUE if the specified string exists in the collection, and FALSE if
it does not. This is illustrated below.
My co-worker and I are having a friendly disagreement as to whether or not
we should rely on an exception to return a result. My coworker's version of
the function and...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look !
Part I. Meaning of...
| |
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: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth.
The Art of Business Website Design
Your website is...
|
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: 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: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one.
At the time of converting from word file to html my equations which are in the word document file was convert into image.
Globals.ThisAddIn.Application.ActiveDocument.Select();...
|
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: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
|
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...
| |