Again, I believe this is a style issue, not a stability issue. A
properly placed assert should trigger due to a fatal condition in the
programming logic. Exceptions are for handling run time issues, but are
often used in place of asserts to handle coding errors at run time. A
mission critical system should be tested to prevent a proper assert from
triggering, and have a watch dog to handle the fatal condition. Although I
would personally pull all of the asserts before going into the field.
73,
Shawn
> -----Original Message-----
> From: Stephen torri [mailto:[EMAIL PROTECTED]
> Sent: Friday, November 07, 2003 2:06 AM
> To: cryptopp
> Subject: Re: Question: why so many asserts?
>
> On Fri, 2003-11-07 at 00:11, Wei Dai wrote:
> > Exceptions are used frequently in Crypto++. They are used to indicate
> well
> > defined error conditions, whereas asserts are used to find programming
> > mistakes. If you hit an exception, you can catch it and continue. If you
> > hit an assert, it means there's a bug in your code or in Crypto++ that
> > needs to be fixed (or possibly there's a hardware error that caused an
> > incorrect calculation).
>
> I believe that asserts should be eliminated. They only cause the program
> to 'Abort' and not give you any reason for why. I found that a simple
> program was failing because I failed to give the full block size for a
> block cipher (3DES). It failed with an abort. I would have been nice to
> receive an exception like InvalidBlockSize. This way I would be forced
> by the design of Crypto++ to be aware of this. I believe this would be
> very helpful for new programmers and for reminding ourselves.
>
> I was thinking about how Crypto++ could be used in more embedded
> devices. These devices might have an ability to be updated with a new
> required information and data but lack any output terminal to alert the
> user that the device failed. As a professor I know at Vanderbilt says
> where is stdout on a missle?
>
> Stephen
> --
> Stephen Torri
> GPG Key: http://www.cs.wustl.edu/~storri/storri.asc
