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

[paulkaefer]

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?

[Reeza · Accepted solution]

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. 

[Quentin]

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.