469,644 Members | 1,955 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,644 developers. It's quick & easy.

Set DEBUG flag at runtime?

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 {
#endif
...
#if !DEBUG
} catch {
#endif
...
#if !DEBUG
}
#endif

Now I'm working for a company where all the code that gets pushed is in DEBUG mode rather than RELEASE. I can't rock the boat enough to change this practice. So now I use this ...

try {
...
} catch {
if (System.Diagnostics.Debugger.IsAttached) System.Diagnostics.Debugger.Break();
...
}

Half the time I am able to move the runtime line of code back into somewhere in the try block or above it, but half the time it just says it can't move off the current line (with seemingly no rhyme or reason). This solution involves a lot more typing than before, as well.

So my question is, is there some way I can simulate the old way of using #if DEBUG, but set the flag at runtime so that the "try {" / "} catch {..}" is not executed as such and I can get the debugger to break exactly where I want it, but be handled gracefully when the debugger isn't attached?

Thanks,
Jon

Mar 7 '07 #1
7 2750
We had a similar problem, and no one ever found a solution for me, but
recently I think found the solution myself. Specifically, I wanted to
always break on exceptions, even if there was a catch block.

In a C# project, look under the Debug Menu->"Exceptions..."(this item
was not initially here on my install, and I had to use the customize
to drag the button/item into the menu).

Adding a check to the "Thrown" column for an exception, or for an
entire catagory of exceptions, will cause them to break even if they
are handled.

I don't think this is exactly what you are looking for, but maybe it
will help.

On Mar 7, 4:24 pm, "Jon Davis" <j...@REMOVE.ME.PLEASE.jondavis.net>
wrote:
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 {
#endif
...
#if !DEBUG} catch {

#endif
...
#if !DEBUG}

#endif

Now I'm working for a company where all the code that gets pushed is in DEBUG mode rather than RELEASE. I can't rock the boat enough to change this practice. So now I use this ...

try {
...} catch {

if (System.Diagnostics.Debugger.IsAttached) System.Diagnostics.Debugger.Break();
...

}

Half the time I am able to move the runtime line of code back into somewhere in the try block or above it, but half the time it just says it can't move off the current line (with seemingly no rhyme or reason). This solution involves a lot more typing than before, as well.

So my question is, is there some way I can simulate the old way of using #if DEBUG, but set the flag at runtime so that the "try {" / "} catch {..}" is not executed as such and I can get the debugger to break exactly where I want it, but be handled gracefully when the debugger isn't attached?

Thanks,
Jon

Mar 7 '07 #2
"Jon Davis" <jo*@REMOVE.ME.PLEASE.jondavis.netwrote in message
news:ue**************@TK2MSFTNGP03.phx.gbl...
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:

Why do you need this?

Michael
Mar 8 '07 #3
Interesting. I don't think I can use that just yet but it might come in
handy. Incidentally, this reminds me again of how much extra functionality
is available tucked away in the toolbar / menu commands.

Jon

"WebSnozz" <sh******@cs.fsu.eduwrote in message
news:11**********************@p10g2000cwp.googlegr oups.com...
We had a similar problem, and no one ever found a solution for me, but
recently I think found the solution myself. Specifically, I wanted to
always break on exceptions, even if there was a catch block.

In a C# project, look under the Debug Menu->"Exceptions..."(this item
was not initially here on my install, and I had to use the customize
to drag the button/item into the menu).

Adding a check to the "Thrown" column for an exception, or for an
entire catagory of exceptions, will cause them to break even if they
are handled.

I don't think this is exactly what you are looking for, but maybe it
will help.

On Mar 7, 4:24 pm, "Jon Davis" <j...@REMOVE.ME.PLEASE.jondavis.net>
wrote:
>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 {
#endif
...
#if !DEBUG} catch {

#endif
...
#if !DEBUG}

#endif

Now I'm working for a company where all the code that gets pushed is in
DEBUG mode rather than RELEASE. I can't rock the boat enough to change
this practice. So now I use this ...

try {
...} catch {

if (System.Diagnostics.Debugger.IsAttached)
System.Diagnostics.Debugger.Break();
...

}

Half the time I am able to move the runtime line of code back into
somewhere in the try block or above it, but half the time it just says it
can't move off the current line (with seemingly no rhyme or reason). This
solution involves a lot more typing than before, as well.

So my question is, is there some way I can simulate the old way of using
#if DEBUG, but set the flag at runtime so that the "try {" / "} catch
{..}" is not executed as such and I can get the debugger to break exactly
where I want it, but be handled gracefully when the debugger isn't
attached?

Thanks,
Jon


Mar 8 '07 #4
On Mar 7, 9:13 pm, "Michael C" <nos...@nospam.comwrote:
"Jon Davis" <j...@REMOVE.ME.PLEASE.jondavis.netwrote in message

news:ue**************@TK2MSFTNGP03.phx.gbl...
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:

Why do you need this?

Michael
It's alot easier to analyze and debug exceptions if execution pauses
right where they occur, so that you can analyze the state of
surrounding objects.

Mar 12 '07 #5
"sh******@cs.fsu.edu" <Aa************@gmail.comwrote in message
news:11*********************@p10g2000cwp.googlegro ups.com...
>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:

Why do you need this?

Michael

It's alot easier to analyze and debug exceptions if execution pauses
right where they occur, so that you can analyze the state of
surrounding objects.
Sure, but if you've handled the exception with a try catch then generally
you did that because you didn't want it to break there.
>

Mar 16 '07 #6

"Michael C" <no****@nospam.comwrote in message
news:et**************@TK2MSFTNGP02.phx.gbl...
>It's alot easier to analyze and debug exceptions if execution pauses
right where they occur, so that you can analyze the state of
surrounding objects.

Sure, but if you've handled the exception with a try catch then generally
you did that because you didn't want it to break there.
You're over-generalizing. "Break" in software speak is not as in breaking
glass, but as in breaking out of a loop; literally it means stop, and debug.
There's no point in stopping and debugging if you've deployed the app in a
released state (what could a user possibly do with a debugger?), but
sometimes if an exception occurs, it's "safe" for the user to continue, but
preferable to trap it when debugging and clean up the conditions.

Jon
Mar 30 '07 #7

"Michael C" <no****@nospam.comwrote in message
news:et**************@TK2MSFTNGP02.phx.gbl...
>It's alot easier to analyze and debug exceptions if execution pauses
right where they occur, so that you can analyze the state of
surrounding objects.

Sure, but if you've handled the exception with a try catch then generally
you did that because you didn't want it to break there.
You're over-generalizing. "Break" in software speak is not as in breaking
glass, but as in taking a break or rest; literally it means stop, and debug.
There's no point in stopping and debugging if you've deployed the app in a
released state (what could a user possibly do with a debugger?), but
sometimes if an exception occurs, it's "safe" for the user to continue, but
preferable to trap it when debugging and clean up the conditions.

Jon
Mar 30 '07 #8

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by Sam Kong | last post: by
3 posts views Thread by ktrvnbq02 | last post: by
2 posts views Thread by msnews.microsoft.com | last post: by
reply views Thread by Jon Davis | last post: by
reply views Thread by gheharukoh7 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.