Date:         Thu, 19 Aug 2004 21:11:56 -0400
Reply-To:     Lou <lpogodajr292185@COMCAST.NET>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         Lou <lpogodajr292185@COMCAST.NET>
Subject:      Re: Open Discussion: To what extent do you implement error
              checking/handling?

"M N" <iced_phoenix_news@YAHOO.COM> wrote in message
news:200408182032.i7IKW3l25874@listserv.cc.uga.edu...
> All,
>
> I suppose I'm especially interested in two aspects:
>
> 1.) Parameter checking in macros
> 2.) SAS error code checking
>
> Clearly, if there are more or less arbitrary requirements set by your
> business or customer such as data range checks, you need to program those.
>
> However, suppose you write a (ridiculously) simple macro:
>
> %macro mysort(DATA=, OUT=, BYVAR=, PRINT=);
>     proc sort data=&DATA out=&OUT;
>        by &BYVAR;
>     run;
>
>     %if &PRINT=YES %then %do;
>         proc print data=&OUT; run;
>     %end;
> %mend mysort;
>
> Now, the PRINT parameter is invented by the programmer rather than being
> tied to a SAS language element.  Thus, I would suggest that the programmer
> should verify that PRINT is equal to YES or NO.

Why?  The macro already checks if the print parameter is equal to YES
(though one wonders why the case should be important) - case aside, if the
parameter is equal to anything else, then presumably the programmer doesn't
want a printed copy of the datasets.  If you're worried about possible
typos, then check just the first letter and make the response case
independent.

> However, the other 3
> parameters are tied to SAS language elements.  Thus, SAS will
> automatically supply error checking on these items.  That said, should any
> of these be checked (i.e. that DATA exists, that OUT is a valid data set
> name, that the BYVAR variable list is valid for DATA)?  Or would you
> simply let SAS spot those errors?  If this is part of a larger, more
> complicated macro, SAS-generated error messages may not be as easy to
> deduce (or as clean in the log) as programmer-generated error messages.

If you're going to do all that checking, maybe it'd be easier to scrap the
macro.  If it's that difficult to deduce the source of the error in a big,
complicated macro, then simplify the macro or rethink the processing
scenario.  In my 20 years of programming with SAS, I'd estimate that better
than half the macros I've run across are overly complicated if not
completely unnecessary.  (That doesn't apply to the macros I've written, of
course.)

> As for the second item I mention above (SAS error code checking), to what
> extent should you check SAS error code variables (SYSERR, SYSRC, SYSINFO
> and friends)?

That depends on the processing scenario - if what you're talking about is an
on-line real time system with a user interface where the LOG is hidden from
the user who in any case isn't a programmer type, then you must cover every
contingency and extensive error checking is mandatory.  Even more especially
so in a Windows type environment, where other applications could conceivably
interfere with the operation of the system, or the user could call up an
explore window and start moving, deleting, and renaming files.

If the scenario is regular production batch-type processing (conceptually
that is - the actual execution might take place in an interactive
environment) handled by a programmer, then the normal error messaging to the
LOG should suffice.

> To what extent do you simply let SAS print its errors to
> the log, and then read the log after the program runs?

> Thanks for your thoughts.
>
> Matt