asm int 3?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Back in the old C++ days we would put an _asm { int 3 } where we wanted the
code to break in to the debugger. (We put this in a TRAP macro to make sure
we walked all code paths.) Is there something like that I can put in a .cs
file?
 
David Thielen said:
Back in the old C++ days we would put an _asm { int 3 } where we wanted the
code to break in to the debugger. (We put this in a TRAP macro to make sure
we walked all code paths.) Is there something like that I can put in a .cs
file?
Click to expand...

Are you already running in a debugger? If so, why not just use a
breakpoint?
 
David,
Back in the old C++ days we would put an _asm { int 3 } where we wanted the
code to break in to the debugger. (We put this in a TRAP macro to make sure
we walked all code paths.) Is there something like that I can put in a .cs
file?
Click to expand...

System.Diagnostics.Debugger.Break();


Mattias
 
David Thielen said:
Back in the old C++ days we would put an _asm { int 3 } where we wanted
the
code to break in to the debugger. (We put this in a TRAP macro to make
sure
we walked all code paths.) Is there something like that I can put in a .cs
file?
Click to expand...

If you realy need an int 3, you'll have to PInvoke kernel32.dll
DebugBreak() API, when you want a managed break do as Mattias said.

Willy.
 
Hi;

What I do is have a method trap(). I place this call at the start of all new
code I write and at the start of every if and else. When I hit these in the
debugger I take them out and trace through the new code I just hit.

This way I make sure I step through every line of code. But in some cases it
is days later that I finally hit one so breakpoints could all be reset by
then.
 
David Thielen said:
What I do is have a method trap(). I place this call at the start of all new
code I write and at the start of every if and else. When I hit these in the
debugger I take them out and trace through the new code I just hit.

This way I make sure I step through every line of code. But in some cases it
is days later that I finally hit one so breakpoints could all be reset by
then.
Click to expand...

Hmm. Personally I don't step through every line of code manually. It
seems a waste of time, when unit tests and code coverage tools can make
sure that not only is all my code being tested, but that it does the
right thing, too - in a way which makes it easy to verify that new
changes haven't broken existing desired behaviour.

Last time I was in a discussion like this, however, I hadn't actually
*done* much unit testing. It had only seemed like a really good idea I
was anxious to try out when I got the chance.

I've now been following a test-driven development model for about 8
months. Over the last couple of days, we've been making changes to the
system which we just wouldn't have considered without unit tests. It
would have been *far* too risky - and there's no way we could have gone
through each line of code manually - it would have taken weeks.

Unit testing really rocks. It's not a panacea - it won't absolutely
stop you from writing bad code. It certainly helps to reduce the number
of bugs (and improve design, when coupled with Inversion of Control)
though. I wouldn't dream of going back at this point.
 
Hi;

I do unit tests up the wazoo too - have done so for a long long time. But I
find it very productive to step through code the first time also.
 
Hi dave,

I think Mattias' System.Diagnostics.Debugger.Break(); should meet your
need, yes? If not, please free feel to tell us your concern, thanks

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
 
Back
Top