|
Buck, the MONITOR op group sounds like a good idea, once we upgrade from v4r5. I'm not sure this group is ready for file I/O isolated in a subroutine. One step at a time. What happens when a File Exception/Error Subroutine is defined for a file and you check for %error right after a chain op? Will the "local" %error test override the INFSR? TIA, Dan --- Buck Calabro <Buck.Calabro@commsoft.net> wrote: > >*every*, I/O operation involving a data > >file is checked with %error. > -snip- > >I just would desire to "hide" the code in a > >faraway routine > -snip- > >Does anyone have practical experience using INFSRs? > > Yes. They are great for catching unexpected errors (like object > damage), > doing a post-mortem DUMP and exiting with an error code set so the > caller > can handle the fact that this program failed. Great for commitment > control. > > As you note, you can't resume at the point of failure. For more > information > on that, check the MONITOR operation. This very list had a thread on > this > topic not too long ago. > > Whatever you decide to do, I might argue that you should keep the I/O > and > it's error handling together. To me, that means wrapping the I/O in > either > a subr call or a procedure call. I prefer a subr because it is very > clear > to me that subrs deal with global variables (like file fields.) > --buck __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus – Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
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.