Subject | Re: [IB-Architect] assert triggers and server aborts |
---|---|
Author | Mike Nordell |
Post date | 2000-08-13T07:46:07Z |
Claudio Valderrama C. wrote:
to. It aborts the process! This is a premature server termination, or ABEND
(ABnormal ENDing), and is not to be taken lightly.
An assert is used to identify illegal states. If this assert is correct,
this is an illegal state and should *never* be allowed to run. The result
should at the best be "undefined", ranging from no measurable ill-effects to
formatting all harddisks. This is *not* something to be taken lightly.
Either the assert is correct, why the error should be fixed, or the
assertion is false and should be removed. There is nothing inbetween.
Sorry if it would seem I came down a bit hard, but this is *very* serious.
/Mike
> BLOBs accept charsets but not collations. Also, when you order by a BLOBIt can't possible be left "as-is". This is a bug, and a pretty serious one
> field, the documentation states this cannot be done and in practice, the
> ordering is using the BLOB_ID.
> So, the release build simply allows such code to run, but the result is
> unmeaningful for the user, unless he/she's really trying to discover the
> order of the BLOB_IDs.
> I think that it should be left as it's. In the debug release, probably an
> assertion is the way to proceed.
to. It aborts the process! This is a premature server termination, or ABEND
(ABnormal ENDing), and is not to be taken lightly.
An assert is used to identify illegal states. If this assert is correct,
this is an illegal state and should *never* be allowed to run. The result
should at the best be "undefined", ranging from no measurable ill-effects to
formatting all harddisks. This is *not* something to be taken lightly.
Either the assert is correct, why the error should be fixed, or the
assertion is false and should be removed. There is nothing inbetween.
Sorry if it would seem I came down a bit hard, but this is *very* serious.
/Mike