When is Debug.Assert pertinent to use ?

  • Thread starter Thread starter Steve B.
  • Start date Start date
S

Steve B.

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
 
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
 
Steve B. said:
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 ?
Click to expand...

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
 
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,

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
Click to expand...

Cheers,
Christoph

Vienna/Austria

www.code4ward.net/blogs/cmn
 
Back
Top