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 7 3004
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
"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
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
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.
"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.
>
"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
"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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Sam Kong |
last post by:
Hello!
I am using VC# 2005 Express Beta.
DEBUG flag is not automatically set when I run at debug mode
#if DEBUG
//...
#endif
|
by: |
last post by:
Hi,
does anyone know what would be the (most common) reasons
to get difference answers in VC++.net between running in
release and debug ?
Thanks,
JC
|
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...
|
by: ktrvnbq02 |
last post by:
Hi,
We have an ASP.NET application built in Release mode via Visual Studio.
All of the C# code is in the code-behind files (i.e. *.aspx.cs files)
and there is no C# in the *.aspx files...
|
by: MLH |
last post by:
I use a fair number of debug.print statements. My apps are
fairly well 'peppered' with them. I've often wondered if leaving
them in the mdb, creating and rolling out an mde intended for
use in the...
|
by: adhingra |
last post by:
I stumbled upon something which does not make sense "Debug class methods are
not automatically suppressed by the managed c++ compiler when the project is
build in release mode"
Create a a...
|
by: msnews.microsoft.com |
last post by:
We are deploying a large .NET 1.1 web app. We are using SP1 of the .NET 1.1
framework. Our build system compiles all of our components in release mode.
We deploy on Windows Server 2003 Enterprise...
|
by: Bern McCarty |
last post by:
I am porting stuff from MEC++ syntax to the new C++/CLI syntax. Something
that we did in the old syntax that proved to be very valuable was to make
sure that the finalizer would purposefully...
|
by: Jon Davis |
last post by:
(Ignore my previous post, had an erroneous sample.)
In order to gracefully handle exceptions at runtime but cause the debugger to break in the place where the exceptions occur when debugging, I...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| |