"tommaso.gasta***@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
>
>

> 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
>
>
> "tommaso.gasta***@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
> >
> >

news:1153864911.955857.220940@75g2000cwc.googlegroups.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
| >
| >
| > "tommaso.gasta***@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
| > >
| > >
|

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

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

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

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