|
Barbara, I understand what you mean, but it is not always as clear cut as you put it.Sometimes overflow can be totally harmless: We had a customer who had, for obscure historical reasons, a field 'Number of times sold this year' in their item file. For even more obscure reasons the field was defined 3P0. Nobody ever looked at the contents of that field. When we converted the program to RPG IV and changed the harmless looking 'ADD 1' to an EVAL, we discovered that it overflowed a few times each week. We were, eh, not enthousiastic about the way we discovered it.
Sometimes overflow can be harmful, but is easily repaired afterwards: I once used too small intermediate fields in a currency calculation, loosing 6 million Dutch Guilders (appr. 3 million dollars) in the process. Luckily it was RPG III, so the process completed normally. The next morning the customer immediately spotted the deficit; they repaired the database with a few corrective bookings and I repaired the program. Had the program stopped at the overflow, I would have had to clean up a half completed invoice process. Believe me, that would have been a mess.
So, overflow can be dangerous and stopping with an error is a sensible default action to take. But I think it was unfair that, until MONITOR was introduced, it was the only possible action and that there was no way for a programmer to deal with it other than delving into condition handlers. Just EVAL(E) would have done the job nicely.
Joep Beckeringh Barbara Morris wrote:
"Lapeyre, Francis" wrote:The way I have it set, no, because there comes a point where adding one to anything can possibly cause an overflow. But you can go into the source and fix it. If I put a 'Z' in the numeric area for that line, it changes to Eval X = X + 1. I only do this if I'm dead sure I'll never overflow the value.If you leave it as ADD, and it overflows someday, wouldn't you want to know about that? Overflow exceptions are a Good Thing. They're like the pain you get when you put your hand in the fire; the pain may be bad, but the burnt hand is worse.
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
