How to make Debug.Assert() behave like a breakpoint in the IDE

[pinkfloydhomer]

I would expect that Debug.Assert() would break into the IDE and stop
on the relevant line of code and highlight it. But instead I get a
dialog asking if I want to abort or ignore etc.

How can I get the behavior I expected?

 

[Peter Duniho]

I would expect that Debug.Assert() would break into the IDE and stop
on the relevant line of code and highlight it. But instead I get a
dialog asking if I want to abort or ignore etc.

How can I get the behavior I expected?

If you want to unconditionally break in the debugger, check the condition
and if it fails, call Debugger.Break(). (It's unfortunate that there's
not a "break always" version of Assert, but you can easily write your own
if it's important enough to you, and just writing a regular if() statement
isn't too hard either ).

Asserts always display a dialog offering you the advice to "Abort"
(terminate the application), "Retry") (break into the debugger), or
"Ignore" (continue execution normally). If you want to break when an
assert happens, just click the "Retry" button.

Pete

 

[pinkfloydhomer]

Asserts always display a dialog offering you the advice to "Abort"
(terminate the application), "Retry") (break into the debugger), or
"Ignore" (continue execution normally). If you want to break when an
assert happens, just click the "Retry" button.

Sure. It just never occurred to me that "Retry" meant "Try exactly one
more time, and then break into the IDE". That feature is good enough
for me, even if the name is a little confusing

/David

 

[Peter Duniho]

Sure. It just never occurred to me that "Retry" meant "Try exactly one
more time, and then break into the IDE". That feature is good enough
for me, even if the name is a little confusing

It is, true. I don't know why the ancient "abort, retry, or ignore"
prompt has survived for so long (it originally being the prompt DOS would
give you when a disk error occurred), and particularly in the context of
an assert where the words aren't exactly descriptive of what will happen
(I think these transferred to Visual Studio when MFC implemented
them...prior to that time, developers would implement their own asserts
and of course use more descriptive names for the buttons).

I would have thought that .NET would be a great opportunity to reword the
buttons. Something like "Exit Application", "Debug Break", and "Ignore"
would be much more obvious IMHO.

But here we are. And to add insult to injury, the docs don't even
describe the UI behavior of the assert dialog. Duh.

Well, anyway...glad you've got a workable solution now.

Pete