I understand all this. I also made some assumptions in my statements. I had assumed that a process was initiated either through an RPC Broker connection or invoking an OPTION from Menuman through proper Kernel sign-on. In both of these cases, the Kernel sets an initial error trap for that process. So this begs the question as to whether or not individual applictions should also set an error trap. If you are not coming in via one of those two avenues, then yes your application should assume the responsibility that the Kernel has always had for VistA. If my application is well defined I should not have <UNDEFINED> or <NULLSUBSCRIPT> type errors. If an occasional error does arise, the Kernel has provided an erro trap to gracefully exit the user instead of just "crashing" the user application. Of course that graceful execution includes logging the error and sometimes stopping the user's process requiring the user to re-signon. Some may say that is not graceful. However, let's look at the VA's approach. How many thousands (or tens of thousands) of sign-on events occur in a single day. Yet, in a well managed system, the error trap is way less than 100 entries, sometimes no entries. Looking at the percentage of error log entries versus the number of sign-on events, the number is so small it does not seem reasonable to ask every application developer to set their own error traps all the time or to excessively protect your code against possible errors for bad data that should not be there in the first place.
In the case for VistA Fileman files, if I have a pointer to file, is it reasonable to always validate in ALL VistA applications that $P(^global(recnum,0),U) is not null? I never check for this. When doing direct global referencing of a file my code usually looks something like this. I am presuming that $D(^global(recnum,0))=1
S X=$G(^global(recnum,0)) I X="" do error condition handling and gracefully quit.
S Y=$P(X,U)
etc...
I never check to see if Y is <NULL>. Yes if all I wanted is the .01 field value from that record I would use something like S X=$P($G(^global(recnum,0)),U) But many times I want other information stored on the zeroth node.
So is it really worth invoking additional error trapping over and above what the Kernel does? I agree that THEORETICALLY, all applications should always protect itself against all that it considers important. But we do not live in a theoretical world. Just checking for possible bad data is not sufficient for a well designed conscientious application. What does the application do if it encounters bad data that it encounters that should not be that way? A good program is going to report that somehow. Who do you report it to? How do you report it? Etc., Etc., Etc.,... Now you have added a lot more source code to handle the proper notification for bad data. With a system as large as VistA you cannot send all these messages to one "recipient".
