DEBUG: can we disable try/catch ?

  • Thread starter Thread starter tommaso.gastaldi
  • Start date Start date
T

tommaso.gastaldi

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
 
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
 
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,
| 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


| 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
| >
| >
| > "(e-mail address removed)" 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
| > >
| > >
|
 
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...
Click to expand...

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
 
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/micro...s.vb/browse_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.

-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/microsoft.public.dotnet.languages.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.
Click to expand...

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.asp
 
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:
 
Back
Top