It is currently Thu Mar 28, 2024 9:13 am


All times are UTC - 8 hours [ DST ]




Post new topic Reply to topic  [ 6 posts ] 
Author Message
 Post subject: Error Processing
PostPosted: Thu Dec 09, 2010 2:27 pm 
Site Admin
User avatar

Joined: Mon Nov 01, 2010 1:58 pm
Posts: 205
Location: Seattle, Washington
Real Name: Frederick D. S. "Rick" Marshall
Began Programming in MUMPS: 15 Jun 1984
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.

I'll use this thread to get started on that project.

_________________
Frederick D. S. "Rick" Marshall, VISTA Expertise Network, 819 North 49th Street, Suite 203, Seattle, Washington 98103, (206) 465-5765, rick dot marshall at vistaexpertise dot net
"The hidden harmony is best." - Heraclitus of Ephesus


Top
Offline Profile  
 
 Post subject: Re: Error Processing
PostPosted: Thu Dec 09, 2010 2:40 pm 
Site Admin
User avatar

Joined: Mon Nov 01, 2010 1:58 pm
Posts: 205
Location: Seattle, Washington
Real Name: Frederick D. S. "Rick" Marshall
Began Programming in MUMPS: 15 Jun 1984
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!

_________________
Frederick D. S. "Rick" Marshall, VISTA Expertise Network, 819 North 49th Street, Suite 203, Seattle, Washington 98103, (206) 465-5765, rick dot marshall at vistaexpertise dot net
"The hidden harmony is best." - Heraclitus of Ephesus


Top
Offline Profile  
 
 Post subject: Re: Error Processing
PostPosted: Thu Dec 09, 2010 2:43 pm 
Site Admin
User avatar

Joined: Mon Nov 01, 2010 1:58 pm
Posts: 205
Location: Seattle, Washington
Real Name: Frederick D. S. "Rick" Marshall
Began Programming in MUMPS: 15 Jun 1984
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.

Troubleshooters everywhere will thank you.

_________________
Frederick D. S. "Rick" Marshall, VISTA Expertise Network, 819 North 49th Street, Suite 203, Seattle, Washington 98103, (206) 465-5765, rick dot marshall at vistaexpertise dot net
"The hidden harmony is best." - Heraclitus of Ephesus


Top
Offline Profile  
 
 Post subject: Re: Error Processing
PostPosted: Fri Jan 28, 2011 3:21 pm 
User avatar

Joined: Wed Nov 17, 2010 4:02 pm
Posts: 71
Location: Houston TX
Real Name: David Whitten
Began Programming in MUMPS: 06 Jan 1982
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.


Top
Offline Profile  
 
 Post subject: Re: Error Processing
PostPosted: Thu Feb 03, 2011 3:19 pm 
User avatar

Joined: Mon Nov 01, 2010 3:33 pm
Posts: 104
Location: Australia
Real Name: Ray Newman
Began Programming in MUMPS: 01 Jul 1976
The advantage here with MV1 is there is no implementation specific error handler; just $ETRAP. It's still very difficult to use tho...


Ray Newman


Top
Offline Profile  
 
 Post subject: Re: Error Processing
PostPosted: Tue Feb 15, 2011 6:15 pm 
Site Admin
User avatar

Joined: Mon Nov 01, 2010 1:58 pm
Posts: 205
Location: Seattle, Washington
Real Name: Frederick D. S. "Rick" Marshall
Began Programming in MUMPS: 15 Jun 1984
That is a big advantage, Ray. Just how much is becoming clearer to me as I come to understand error processing better.

_________________
Frederick D. S. "Rick" Marshall, VISTA Expertise Network, 819 North 49th Street, Suite 203, Seattle, Washington 98103, (206) 465-5765, rick dot marshall at vistaexpertise dot net
"The hidden harmony is best." - Heraclitus of Ephesus


Top
Offline Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 posts ] 

All times are UTC - 8 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 10 guests


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

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Theme created StylerBB.net