This is going to be a very very very long-running thread about standard error processing, a difficult subject that continues to trip up even the best, most experienced mumpsters.

I'll just start by saying that you really shouldn't combine vendor-specific error processing and standard error processing in the same MUMPS job. Not only are the rules for each one separately complex, not only are the standard features inadequately understood by any living mumpster, not only are there ambiguities and inconsistencies in the current standard's description of error processing, not only is that description among the tersest things I've ever read (as far as the ratio of meaning to words, i.e., the amount of unpacking needed to fully comprehend what it says), not only are the vendor-specific features different for every vendor - even when they use the same names for language elements like $ztrap - but in addition as I learned this week precisely how the vendor-specific elements interact with the standard ones varies from vendor to vendor and in some cases can even be modified by vendor switches to interact differently at differently times within the same implementation.

This came up when we found run-away jobs at Oroville hospital consuming 100% of the CPU. The trigger was a bug in George Lilly's ePrescribing package, which he fixed, but what should have happened is that his error should have been logged and the job halted. It was not George's fault that didn't happen. I'm still conducting an analysis of the problem, but it looks like it was the fault of Rob Tweed's EWD package, which instead of letting the Kernel handle error trapping tries to do so itself, using the nonstandard $ztrap intrinsic function, not noticing that the Kernel had already set up trapping with $etrap.

As I noted above, the interactions involved are very tricky and I'm fairly sure I don't know a single VISTA programmer (including myself and Wally) who has mastered them. When EWD modifies $ztrap, it inadvertently created a condition that led to an error loop, in which errors result in 100% CPU consumption as trapping an error leads to another error and another and another, all without triggering the standard MUMPS conditions that lead to the process being halted to avoid this exact condition.

There are also IHS programs that manipulate the error trap, and we've been intermittently having problems with runaway jobs from them, as well.

Later I'll more fully explore the specific scenario, but for now let's just start out our discussion of error handling by saying avoid it if you possibly can. If you're writing foundational software - in VISTA that would be Sign-on, Broker, Taskman, and possibly one or two other things - then you need to write error-processing code to protect the rest of the system. If not, there are very few situations in which you legitimately ought to be touching the stuff, and if you should then use the standard features only, not the vendor-specific ones. More generally, if the system you're working on is based on standard features, stick with them; if vendor-specific features, stick with those. Mixing and matching is asking for trouble. If you don't know what your foundational software uses, then you don't know enough about your system to be justified in touching the error-processing features.

This is not meant as a dig on anyone. Error handling is very complex in MUMPS, and is orthogonal to the way we usually think about software since it involves stack manipulation, interrupts, and code substitution, all at the same time. The standard's explanation is nearly impenetrable, and no published description of it to date gets into enough detail about it to ensure you can avoid getting into trouble. Worst of all, the trouble you can cause is bad enough that it forces people to drop everything they're doing, and is obscure enough in its causes that it is a nightmare to troubleshoot.

Like indirection, MUMPS error processing is a small step over a very deep chasm. Unlike indirection, I recommend you avoid error processing if you possibly can until we get some fuller accounts of it published.

To clarify, the MUMPS standard says precisely nothing about the interactions between the standard error-processing features and the vendor-specific ones.

That's because the standard's approach to all things implementation-specific is silence. It takes a positive-only approach to standard MUMPS, saying what is standard but nothing about what isn't.

Therefore, you can't learn about the interactions between the two by reading the standard or any fuller explication of it. You have to study and master the materials published by your implementor as well as the standard publications, which as far as I can tell nobody has done yet.

Also, to amplify my previous post, I'm classifying error processing as part of advanced MUMPS, meaning not only do you have to understand everything basic or intermediate before you have a shot at getting it right, it's difficult to understand, easy to screw up, and the screw ups can create problems that are both serious and hard to troubleshoot.

One of the differences between MUMPS and a lot of other programming languages is that MUMPS doesn't hold your hand or put up fences to protect you. You have to develop the discipline within yourself to avoid jumping off the many cliffs it makes available to you, or hanging yourself with the rope it gives you. With just a few characters in VISTA you can shut down a running production system or delete the Patient file, and all MUMPS-based medical systems are this way.

Programming in MUMPS means playing with serious levels of power, for good or ill. It's each mumpster's responsibility to come to grips with the full meaning of that power and to learn to steer clear of problem areas on their own. In our increasingly Orwellian modern world, there aren't a lot of places in life anymore where you are thrown entirely upon your own resources to do the right thing, but this is one of them.

When we describe something as being mumpsy, that's part of what we mean, that it's simultaneously terse, powerful, and dangerous, and therefore asks more mature judgment of the programmer than many other languages would. MUMPS's approach to error processing is very mumpsy indeed. Programmer beware!

So to summarize for now, if you are writing code intended to be used with VISTA, RPMS, or related dialects, and you have used nonstandard error-processing features like $ztrap, I urge you to review your code. If you can get away without doing any error processing yourself, just strip out that code and refactor the related code so it can do without it. If you absolutely have to do your own error processing, replace your nonstandard, nonportable features with standard ones and refactor the code to handle the differences. If you aren't sure, start a thread under MUMPS Projects to post the sample code and ask for help; it's what we're here for.

I have heard people argue that there is a difference between Error processing and Exception processing.They use a definition that Error processing is what you code does when something occurs that the programmer does not expect, and Exception Processing is what the code does when some unusual event or condition occurs that the programmer does expect.

An example of this is reading from a text file. The general case for code processing from a text file is that a READ will get a line of data from the file. The Exception is that there will be no more information available to READ because there is an end-of-file. The programmer knows that every file has an end-of-file, and as a program sequentially reads the information in the file, eventually the code will encounter the end-of-file. An Error would be that some other process deletes the file currently being read, or the disk drive containing that file is turned off. The original programmer might surmise that these conditions are possible, but there is no reason that the program should be written to deal with these conditions as if they occur, the program can't do anything else, but stop processing. If the program treats these Errors as if they were the same as an end-of-file Exception, inappropriate actions might be performed.

This distinction between Exception Processing and Error Processing is not supported by the current MUMPS Standard. Whether it should be made or should not be would be a decision for the Standards making body.

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum