473,324 Members | 2,456 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,324 software developers and data experts.

DEBUG: can we disable try/catch ?

It would be useful, sometimes, when debugging, to disable
all the try /catch one has in the program (clearly not commenting them
out).

Any info or hint on that?

-tom

Jul 25 '06 #1
7 8635
Tom,

In VS2003 choose Exceptions from the Debug menu. Select Common Language
Runtime Exceptions and click the Break into the Debugger option.

I'm sure there is a similar option in VS2005.

Kerry Moorman
"to**************@uniroma1.it" wrote:
It would be useful, sometimes, when debugging, to disable
all the try /catch one has in the program (clearly not commenting them
out).

Any info or hint on that?

-tom

Jul 25 '06 #2
Thanks Kerry. I can see it's slightly different here (2005), but works
fine.

Thanks, this is useful indeed!

Not sure why the default is unchecked, I think when debugging we
usually want to know where exactly is the problem :) ...

-tom

Kerry Moorman ha scritto:
Tom,

In VS2003 choose Exceptions from the Debug menu. Select Common Language
Runtime Exceptions and click the Break into the Debugger option.

I'm sure there is a similar option in VS2005.

Kerry Moorman
"to**************@uniroma1.it" wrote:
It would be useful, sometimes, when debugging, to disable
all the try /catch one has in the program (clearly not commenting them
out).

Any info or hint on that?

-tom
Jul 25 '06 #3
Tom,
| Not sure why the default is unchecked, I think when debugging we
| usually want to know where exactly is the problem :) ...
Generally only if I am debugging the exception handling itself.

Most of the time when debugging I want my try/catch blocks to catch the
exceptions, as that is their job. I really don't want to be "bothered" with
every exception, when debugging, as I am much more interested in the code
that I am debugging. The exceptions are generally unrelated to the code that
is currently being debugged.

Of course when the exception is related to the code being debugged, then
yes, by all means, I want to know exactly where the exception occurred &
what the stack (local variables, parameters) look like in that routine &
possibly the routines that called it...

--
Hope this helps
Jay B. Harlow [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net
<to**************@uniroma1.itwrote in message
news:11**********************@75g2000cwc.googlegro ups.com...
| Thanks Kerry. I can see it's slightly different here (2005), but works
| fine.
|
| Thanks, this is useful indeed!
|
| Not sure why the default is unchecked, I think when debugging we
| usually want to know where exactly is the problem :) ...
|
| -tom
|
| Kerry Moorman ha scritto:
|
| Tom,
| >
| In VS2003 choose Exceptions from the Debug menu. Select Common Language
| Runtime Exceptions and click the Break into the Debugger option.
| >
| I'm sure there is a similar option in VS2005.
| >
| Kerry Moorman
| >
| >
| "to**************@uniroma1.it" wrote:
| >
| It would be useful, sometimes, when debugging, to disable
| all the try /catch one has in the program (clearly not commenting them
| out).
|
| Any info or hint on that?
|
| -tom
|
|
|
Jul 26 '06 #4
Tom,
| Not sure why the default is unchecked, I think when debugging we
| usually want to know where exactly is the problem :) ...
Generally only if I am debugging the exception handling itself.
Most of the time when debugging I want my try/catch blocks to catch
the exceptions, as that is their job. I really don't want to be
"bothered" with every exception, when debugging, as I am much more
interested in the code that I am debugging. The exceptions are
generally unrelated to the code that is currently being debugged.

Of course when the exception is related to the code being debugged,
then yes, by all means, I want to know exactly where the exception
occurred & what the stack (local variables, parameters) look like in
that routine & possibly the routines that called it...
To give a concrete example of why you don't want it checked. In 2002/2003
the implemtation for IsDate inside of the framework raised an internal exception,
caught it and returned false if the value wasn't recognizable as a valid
date. If you set the debugger to break on all errors, it would break inside
of the framework which is clearly somewhere you can't modify. Since they
are catching and handling the exception, there is no reason you should care
if there was an exception there (other than the performance implications
of exception handling). Luckily, they changed the date parsing routines (using
TryParse) and have eliminated the internal exceptions in 2005.

Jim Wooley
http://devauthority.com/blogs/jwooley/default.aspx
Jul 26 '06 #5

Yes Jay and Jim, Thanks for the enlighting examples.

You are right. Actually, one thing
that would be useful, I think, and I do
not know if it is already envisioned by
the compiler, would be, once one has
enabled breaking, the possibility
to disable the "break into code" for some
particular Try catch.

For instance in the code I posted some day
ago

http://groups.google.it/group/micros...fe2f0fc9?hl=it
Try
TcpListener.Start()
Catch ex As Exception
MsgBox("Port may be already in use by another app" & _
vbCrLf & ex.Message)
Exit Sub
End Try

the try catch is somehow "part of the program"
just because I do not have a better way to
check if the port is busy. If I had it
I would not need the try catch.

But in other cases were the try catch serves
really to catch unexpected exceptions, one
would like that at debug time the exception
be precisely located.

So I would like in general, during debug, to have the
"break in code" active, BUT *for some* try catch
(like the one above) I would like the try catch
work normally.

I am just wondering if it is possible to ask
the compiler to behave this way, which I think
would be most useful during development.

-tom
Jim Wooley ha scritto:
Tom,
| Not sure why the default is unchecked, I think when debugging we
| usually want to know where exactly is the problem :) ...
Generally only if I am debugging the exception handling itself.
Most of the time when debugging I want my try/catch blocks to catch
the exceptions, as that is their job. I really don't want to be
"bothered" with every exception, when debugging, as I am much more
interested in the code that I am debugging. The exceptions are
generally unrelated to the code that is currently being debugged.

Of course when the exception is related to the code being debugged,
then yes, by all means, I want to know exactly where the exception
occurred & what the stack (local variables, parameters) look like in
that routine & possibly the routines that called it...

To give a concrete example of why you don't want it checked. In 2002/2003
the implemtation for IsDate inside of the framework raised an internal exception,
caught it and returned false if the value wasn't recognizable as a valid
date. If you set the debugger to break on all errors, it would break inside
of the framework which is clearly somewhere you can't modify. Since they
are catching and handling the exception, there is no reason you should care
if there was an exception there (other than the performance implications
of exception handling). Luckily, they changed the date parsing routines (using
TryParse) and have eliminated the internal exceptions in 2005.

Jim Wooley
http://devauthority.com/blogs/jwooley/default.aspx
Jul 26 '06 #6
You are right. Actually, one thing
that would be useful, I think, and I do
not know if it is already envisioned by
the compiler, would be, once one has
enabled breaking, the possibility
to disable the "break into code" for some
particular Try catch.
For instance in the code I posted some day
ago
http://groups.google.it/group/micros...nguages.vb/bro
wse_frm/thread/33105b50fe2f0fc9?hl=it
Try
TcpListener.Start()
Catch ex As Exception
MsgBox("Port may be already in use by another app" & _
vbCrLf & ex.Message)
Exit Sub
End Try
the try catch is somehow "part of the program"
just because I do not have a better way to
check if the port is busy. If I had it
I would not need the try catch.
But in other cases were the try catch serves
really to catch unexpected exceptions, one
would like that at debug time the exception
be precisely located.
So I would like in general, during debug, to have the
"break in code" active, BUT *for some* try catch
(like the one above) I would like the try catch
work normally.
I am just wondering if it is possible to ask
the compiler to behave this way, which I think
would be most useful during development.
If you only want to catch it while debugging, you can use Debug.Assert rather
than a message box. The assert will be ignored when compiled as a release
build. Additionally you can use conditional compilation directives (#if...#End
If) to handle dynamic configuration issues for the compiler to evaluate.

Typically a catch block should be used only if you can actually do something
about the exception (like trying another port). Otherwise, just let the exception
bubble up to a level that can handle it (logging, notification, etc). Also,
if you know that a specific exception may be invoked as part of your method
(TcpListener.Start), only catch the specific exception type you already know
is a fringe case. Don't blanket swallow all exceptions.

Jim Wooley
http://devauthority.com/blogs/jwooley/default.aspx
Jul 26 '06 #7
Thanks Jim.

I have also found this nice article on the subject:

http://www.devx.com/dotnet/Article/31414/1954?pf=true

at the present I begin to feel that the most practical solution is, as
the article seems to suggest, is to check boxes in the "Thrown" and use
F5 to resume when there are exception expected (like a closed
oledbconnection , etc.) ... have to see, using it, if there are
disadvantages... :)

-tom

Jim Wooley ha scritto:
You are right. Actually, one thing
that would be useful, I think, and I do
not know if it is already envisioned by
the compiler, would be, once one has
enabled breaking, the possibility
to disable the "break into code" for some
particular Try catch.
For instance in the code I posted some day
ago
http://groups.google.it/group/micros...nguages.vb/bro
wse_frm/thread/33105b50fe2f0fc9?hl=it
Try
TcpListener.Start()
Catch ex As Exception
MsgBox("Port may be already in use by another app" & _
vbCrLf & ex.Message)
Exit Sub
End Try
the try catch is somehow "part of the program"
just because I do not have a better way to
check if the port is busy. If I had it
I would not need the try catch.
But in other cases were the try catch serves
really to catch unexpected exceptions, one
would like that at debug time the exception
be precisely located.
So I would like in general, during debug, to have the
"break in code" active, BUT *for some* try catch
(like the one above) I would like the try catch
work normally.
I am just wondering if it is possible to ask
the compiler to behave this way, which I think
would be most useful during development.

If you only want to catch it while debugging, you can use Debug.Assert rather
than a message box. The assert will be ignored when compiled as a release
build. Additionally you can use conditional compilation directives (#if...#End
If) to handle dynamic configuration issues for the compiler to evaluate.

Typically a catch block should be used only if you can actually do something
about the exception (like trying another port). Otherwise, just let the exception
bubble up to a level that can handle it (logging, notification, etc). Also,
if you know that a specific exception may be invoked as part of your method
(TcpListener.Start), only catch the specific exception type you already know
is a fringe case. Don't blanket swallow all exceptions.

Jim Wooley
http://devauthority.com/blogs/jwooley/default.aspx
Jul 26 '06 #8

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

1
by: marco_segurini | last post by:
Hi, At the moment I am using Visual Studio 2005 beta 1. The following program does not compile using the debug configuration setting the "Disable Language Extensions" flag to "Yes(/Za)" while...
4
by: Angel | last post by:
I am trying to debug a simple asp.net project using Visual Studio.net(2002) and receive the following error: Error while tring to run project. Unable to start debugging on the web server....
12
by: nospam | last post by:
All the documentation says that leaving an ASP.NET application in debug mode has a big performance hit. I can't detect any difference between debug and non-debug modes. Am I missing something or is...
8
by: ST | last post by:
Hello everyone, Can anyone help me with this error above when I debug my web app project in vstudio.net?? I can't figure it out! It was working fine for months, and now all of a sudden it's not!!...
2
by: Michael | last post by:
Running DB2 v7 UDB ("DB2 v7.1.0.93", "n031208" and "WR21333") on Windows XP, I am unable to find out why the "Build for Debug" option within Stored Procedure Builder is not enabled on Java stored...
25
by: pamelafluente | last post by:
Hi Guys, I have the following HTML code which is doing a GET to a page, say MyUrl.aspx : <body> <form name="form1" method="get" action="MyUrl.aspx" id="form1"> <input type="hidden"...
7
by: Jon Davis | last post by:
In order to gracefully handle exceptions at runtime but cause the debugger to break in the place where the exceptions occur when debugging, I used to write code like this: #if !DEBUG try {...
2
by: mthread | last post by:
Hi, I am new to C++, But has good experience in C. In C I have used macros to enable / disable debug statements in the code. For ex : #if defined ENABLE_DEBUG #define Printf1(arg) printf(arg)...
2
by: joelkeepup | last post by:
Hi, I made a change this morning and now im getting an error that says either "a is undefined or null" or "e is undefined or null" the microsoft ajax line is below, I have no idea how to...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.