When is Debug.Assert pertinent to use ?

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Steve B. - 21 Jun 2006 13:42 GMT

Hi,

I'm wondering when does Debug.Assert is pertinent to use.

For the moment, I think it is used to ensure something is true, as it is
supposed to be always true.

For example, I query a DB to get the only one customer's detail rows.
If I get any exception, it is an runtime error..So I use try/catch/throw
blocks.
If I get 0 rows, it is a business error, so I throw a business exception.
If I get 1 row, it's ok and I return it.
If I get 2 or more row, it's a supposed-impossible case, but I use
Debug.Assert to check it actually does not occurs. If it occurs, it should
help me debug the application.

Am I on the right way ?

Steve

Reply to this Message

Markus Kling - 21 Jun 2006 16:51 GMT

Steve,

you should use error handling code (exceptions) for conditions you expect to
occur and assertions for conditions that should never occur.

In other words, the general strategy is to use asserts everywhere where
something must to be true and it not being true would be a programming error
of some type. Exceptions should be used where it is an error condition that
could happen in a real system but is relatively unusual (like your method
not returning a record).

Imho your approach is right.
Markus

> Hi,
>
[quoted text clipped - 15 lines]
>
> Steve

Reply to this Message

Jim Wooley - 21 Jun 2006 20:54 GMT

Also, remember that the Debug.Assert portions are for developer time issues
only. They are excluded on release build so they won't be fired when one
of the situations outside the expected hits on a deployed app.

Jim Wooley
http://devauthority.com/blogs/jwooley/default.aspx

> Steve,
>
[quoted text clipped - 31 lines]
>>
>> Steve

Reply to this Message

David Browne - 21 Jun 2006 18:55 GMT

> Hi,
>
[quoted text clipped - 13 lines]
>
> Am I on the right way ?

No. Debug.Assert does not affect the control flow and is not triggered in
release builds. All of the Debug. methods are generally not very usefull.
Use System.Diagnostics.Trace to output trace information, and use Exceptions
to indicate program failures.

You should throw an Exception (perhaps an InvalidOperationException), when
something bad happens. This will stop code execution both in debug and
release builds, and give you the stack trace information to debug it.

David

Reply to this Message

Christoph Richter [AT] - 22 Jun 2006 00:07 GMT

the real benefit is, that with debug.assert you have also an stop
output window. where i use it most times is, that theres an
specification, that the pages of the aspnet site, for excample are not
allowed to exceed 40kb. so i make an function, that check the size of
the output page, and debug.assert that its smaller.... so i can
develop and if i exceed it, i'll know it right away....

so stuff, thats not directly true false, but for warnings, when you
exceed some parameters....

cheers,
christoph

>Hi,
>
[quoted text clipped - 15 lines]
>
>Steve

Cheers,
Christoph

Vienna/Austria

www.code4ward.net/blogs/cmn

Reply to this Message

When is Debug.Assert pertinent to use ?

Free Magazines