Monthly Archives: January 2012
A few days ago while I was working on a new monitoring script for our SAP systems, one of the SAP team members came by and said: “I just got the strangest error message on my screen, did I break something?”
Above is the error message in a screenshot I took to memorialize the event. One thing I know is that a joke that requires explaining is likely not very effective. For any non-Americans: in the US a pool table is a pocket billiard table. This caused the first bit of confusion. Secondly, for the majority of us for whom SQL is not a second or – God forbid – first language “LIKE with ESCAPE” has absolutely no meaning.
So to the person who alerted me to this, it appeared that somehow their actions had caused SAP to collapse into a state of returning random meaningless phrases — SAP’S BROKE! The short story, of course is that SAP was not broken. Instead a diligent programmer provided an informational message to warn against using a search string with the “_” character in it. Of course the search returned valid results, did not run for 30 minutes or any other bad thing.
I began reflecting on how difficult great programming really is. Creating the code to work as designed, returning valid information is a great accomplishment. Building in the facility to react reasonably to the input from the human interface adds further complication and skill. If I had one recommendation for the SAP style guide it would be that when an entry field contains input that is not expected (ie non-numeric) PLEASE, PLEASE do not generate an ABAP dump, instead return a message pointing out the field requiring correction.
Alternatively, I offer my standard error return code in the spirit of Open Source:
echo “Dear %username% that is incorrect. In order to prevent further computational error/abuse the hard drive on this computer will self-destruct in
5 …. 4…..3…..2…..1………………………………………………………………….”
terminate 2>&1 >/dev/null
Share your favorite confusing messages in the comments. I’d love to hear or see them!