DATA Step, Macro, Functions and more

why separate 'ERR' from 'OR' when printing error messages to the log?

Accepted Solution Solved
Reply
Regular Contributor
Posts: 175
Accepted Solution

why separate 'ERR' from 'OR' when printing error messages to the log?

I've seen a few places, including here, the recommendation to put 'ERR' and then 'OR: <error message>' when printing a user-defined error message to the log.

 

I tried it to see the difference from simply putting it all in one string:

 

data _NULL_;
    put 'ERROR: this is an error';
    put 'ERR' 'OR: this is another';
run;

They both seem to work the same way. Is this something that was more important in the past?


Accepted Solutions
Solution
‎05-03-2016 04:11 PM
Super User
Posts: 19,822

Re: why separate 'ERR' from 'OR' when printing error messages to the log?

Posted in reply to paulkaefer

I think this had to do with avoid log parsing tools that scanned the logs for errors in a company. No production code can have the word ERROR in it. 

View solution in original post


All Replies
Solution
‎05-03-2016 04:11 PM
Super User
Posts: 19,822

Re: why separate 'ERR' from 'OR' when printing error messages to the log?

Posted in reply to paulkaefer

I think this had to do with avoid log parsing tools that scanned the logs for errors in a company. No production code can have the word ERROR in it. 

PROC Star
Posts: 1,322

Re: why separate 'ERR' from 'OR' when printing error messages to the log?

Agree with @Reeza that it is for easier log scanning.  In my experience, when people have a log scanning program (SAS or other), it is usually smart enough to distinguish between the word "ERROR" in code and an actual ERROR message in the log (in particular, in the log the line will start with "ERROR"). 

 

But in the setting where a person (or group) does not have a log scanning utility, often people resort to a quick-and-dirty scan of the log by just using CTRL-F for find.  In that case, if the word "ERROR" appears in code, it will be caught by the FIND command.  And if it happens too many times, the user might just give up on log review (which is always a bad idea...) 

 

So separating into "ER" "ROR" makes code uglier but easier for a naive log review (which is worse than an automated log review but better than no log review).

 

In my macros I do the even uglier: %PUT ER%str()ROR:  <Blah>;   I have a function key / keyboard macro assigned to generate PUT "ER" "ROR:" and %PUT ER%str()ROR: , which saves a little typing. 

☑ This topic is solved.

Need further help from the community? Please ask a new question.

Discussion stats
  • 2 replies
  • 248 views
  • 2 likes
  • 3 in conversation