×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
I think the basic summary is that
- if you expect rare to none exceptions to be trapped by monitor then
performance wise, it blows away constantly testing the values
- If, however, you expect frequent occasions then other testing might be
better.
Using a monitor may help bullet proof your code. Think of items that you
haven't thought of. Like you're testing a date but assuming that if it's
incorrect it's a zero date. Not really a monitor issue, but just an
example.
Or things that may change in the future. A recompile refreshes variable
sizes and now you get more truncation errors. Someone added referential
integrity to the database and your write fails due to other issues than
the record is already there (like the parent record isn't or the trigger
program threw an exception).
There's a lot of code out there like
write record;
if %error;
chain ...
balance += TranAmt;
update...
endif;
which brings up the classic example of assume.
Rob Berendt
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
