Set DEBUG flag at runtime?

[Jon Davis]

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

 

[WebSnozz]

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.

 

[Michael C]

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

 

[Jon Davis]

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

 

[shumaker]

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.

 

[Michael C]

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.

 

[Jon Davis]

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

 

[Jon Davis]

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