|
rob=tksaTn4SAz0AvxtiuMwx3w@public.gmane.org wrote: > > This will make the logic kind of confusing > Monitor; > read (e) myfile; > Select; > When %status=NoError; // Good read > ... > When %status=EndOfFile; // Break out of loop > ... > When %status=RecordNotFound; // Strange > ... > EndSl; > // Check for other errors > On-Error TriggerErrBef; // Trigger error, maybe we don't have access? > ... > On-Error FileClosed; // Oops, need to open the file > ... > On-Error; // Catch all for other errors > ... > EndMon; > Rob, in this case, maybe a select -would- be better. MONITOR wasn't intended to replace (e). It was more intended to handle the cases where the *PSSR is the only handler, for the cases where you want to continue. Just code a calculation in a MONITOR without having to check in advance that it won't crash (thereby avoiding the trip to the *PSSR for an allowable error). It can also simplify exception handling for I/O opcodes in a subprocedure; if you just want to fail the subprocedure if any error at all occurs, you can use a big MONITOR and not have to bother with (e) and %error-checking on every I/O. > > Why didn't they allow the sub 100's to be trapped for? > MONITOR was intended for exception handling. I can see that being able to monitor for status codes between 1 and 99 could be useful. But I don't think that you should be able to monitor for a status of 0. By the way, it was probably a typo, but if you code read(e), the (e) will handle all the file errors, so your on-errors will never fire.
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.