Comment On The Pyramid of Error

Scary. Just scary.

Captcha:
doom

HA!

So this is broken-register syndrome? If it fails the first time, do it a few more times to make sure it really takes?

His reward was the understanding that error is set to 1 when any error occurs, not just file i/o errors.

Error is set on any error, the value depends on its kind and is probably not 1.

C has a lot of potential for bad code, but logging to stderr that it failed to log on stderr is really creative.

My brain hurts.

I found the problem! the commenter used the wrong form of its. The one written there is the possessive, not the contraction for it is. I'll have to be careful in my comments from now on so I don't end up on this website.

Captcha: burned.

Oh, I see! It should have been:

if (error)

  while (fprintf(stderr,"An error occured while writing to the file")<0);

That's much cleaner...

This code is so naff, but my favourite is the belief that fprintf returns less than zero on error. fprintf returns the number of characters printed - on failure it sets errno.

captcha: I'm not telling you

This could be worse.
The system I'm testing atm used to log any kind of errors to the windows eventlog.
Even if the error is that it doesn't have the rights to write to the windows eventlog....

I've never seen logfiles (the redundant log-method) being written that fast :)

Mcoder:

His reward was the understanding that error is set to 1 when any error occurs, not just file i/o errors.

Error is set on any error, the value depends on its kind and is probably not 1.

C has a lot of potential for bad code, but logging to stderr that it failed to log on stderr is really creative.

In my military-subcontractor days, I once saw someone actually do something like this (on a system that could run interactively, or as a headless daemon):

// paraphrasing...

try {

    // ...

} catch (Exception e) {

  try {

      // write error to message queue

  } catch (MessageQueueException mqe) {

    try {

        // write error to message log

    } catch (IOException ioe) {

      // log file not accessible

      try {

          // print to stderr

      } catch (Throwable t1) {

        // Someone closed 2: might be running as daemon

        try {

            // print to stdout

        } catch (Throwable t2) {

          // Someone closed 1: might be running as daemon

          // intentionally do a divide-by-zero error

          // to force underlying system to puke

        }

      }

    }

  }

}

This was repeated in every single place where an error occurred. It could have been done once in a common block of error handling code. <Sigh/>

Mcoder:

His reward was the understanding that error is set to 1 when any error occurs, not just file i/o errors.

Error is set on any error, the value depends on its kind and is probably not 1.

I think you are confusing 'error' with 'errno'.

bstorer:

Oh, I see! It should have been:

if (error)

  while (fprintf(stderr,"An error occured while writing to the file")<0);

That's much cleaner...

No, no. You want to spawn a thread on each pass of the loop - what else are all these SMP and multicore machines for?

snoofle:

Mcoder:

His reward was the understanding that error is set to 1 when any error occurs, not just file i/o errors.

Error is set on any error, the value depends on its kind and is probably not 1.

C has a lot of potential for bad code, but logging to stderr that it failed to log on stderr is really creative.

In my military-subcontractor days, I once saw someone actually do something like this (on a system that could run interactively, or as a headless daemon):

        } catch (Throwable t2) {

          // Someone closed 1: might be running as daemon

          // intentionally do a divide-by-zero error

          // to force underlying system to puke

        }

This was repeated in every single place where an error occurred. It could have been done once in a common block of error handling code. <Sigh/>

Not to mention printing a stacktrace from the original exception and calling System.exit(1); rather than forcing a divide by zero.

I don't see where it logs "File Not Found"

CrystalMethod:

snoofle:

Mcoder:

His reward was the understanding that error is set to 1 when any error occurs, not just file i/o errors.

Error is set on any error, the value depends on its kind and is probably not 1.

C has a lot of potential for bad code, but logging to stderr that it failed to log on stderr is really creative.

In my military-subcontractor days, I once saw someone actually do something like this (on a system that could run interactively, or as a headless daemon):

        } catch (Throwable t2) {

          // Someone closed 1: might be running as daemon

          // intentionally do a divide-by-zero error

          // to force underlying system to puke

        }

This was repeated in every single place where an error occurred. It could have been done once in a common block of error handling code. <Sigh/>

Not to mention printing a stacktrace from the original exception and calling System.exit(1); rather than forcing a divide by zero.

Well, it's kind of a mixed bag. If it was running as a daemon, simply printing a stack trace wouldn't work as stdout/error would have been closed, thus leaving no place for the trace to be printed. However, the way they attempted to handle it in those cases was admittedly inept.

Duston:

I don't see where it logs "File Not Found"

true... or false...

Captcha: Wigwam. basically the same shape as a pyramid, but easier built. :)

CrystalMethod:

This code is so naff, but my favourite is the belief that fprintf returns less than zero on error. fprintf returns the number of characters printed - on failure it sets errno.

Then why does the NetBSD manpage on fprintf contain this:

Upon successful completion printf(), fprintf(), vprintf(), and vfprintf()
return the number of characters printed. Otherwise a negative value is
returned and errno is set to indicate the error.

CrystalMethod:

bstorer:

Oh, I see! It should have been:

if (error)

  while (fprintf(stderr,"An error occured while writing to the file")<0);

That's much cleaner...

No, no. You want to spawn a thread on each pass of the loop - what else are all these SMP and multicore machines for?

You're right! My code is horribly inefficient. Let's fix it:

if (error)

  while (fprintf(stderr,"An error occured while writing to the file")<0)

    fork ();

That's much better. But maybe we should add a sleep statement in there, because any error with stderr is bound to be fixed in, say, 30 seconds:

if (error)

  while (fprintf(stderr,"An error occured while writing to the file")<0)

  {

    fork ();

    sleep (30);

  }

The REAL WTF is ...

everyone: ASL???

Paula, No Quack!
VB
Wooden Table

Step 1: Underwear
Step 2:
Step 3: Profit!

captcha: wigwam

bstorer:

CrystalMethod:

bstorer:

Oh, I see! It should have been:

if (error)

  while (fprintf(stderr,"An error occured while writing to the file")<0);

That's much cleaner...

No, no. You want to spawn a thread on each pass of the loop - what else are all these SMP and multicore machines for?

You're right! My code is horribly inefficient. Let's fix it:

if (error)

  while (fprintf(stderr,"An error occured while writing to the file")<0)

    fork ();

That's much better. But maybe we should add a sleep statement in there, because any error with stderr is bound to be fixed in, say, 30 seconds:

if (error)

  while (fprintf(stderr,"An error occured while writing to the file")<0)

  {

    fork ();

    sleep (30);

  }

.


Ahem... (Ok, I am intermixing C and Java here, but still):

if (error) {

  try {

      while (fprintf(stderr,"An error occured while writing to the file")<0)

        {

          fork ();

          sleep (30);

        }

  } catch (IOException ioe) {

    // stdout has been closed: file-not-found!

  }

}

Duston:

I don't see where it logs "File Not Found"

If the log file is not found, how can you expect to see it?

You might [?] that this would prevent these forces from interacting with computers

You might what?

snoofle:

So this is broken-register syndrome?

Sorry, is that an actual term? I can't find it anywhere, but it sounds interesting.

If at first you don't succeed....failure is probably your style.
http://www.despair.com/los24x30prin.html

my favourite is the belief that fprintf returns less than zero on error.

This is actually true. My Linux manpage and BSD (from the BSD man page CGI) confirm it. This is an ANSI function, so i assume it would be the same everywhere.

on failure it sets errno.

Technically true, but one could read this to say you don't need to check return values, just check errno. errno could be set on any subfunction calls (maybe i'm writing to a socket, and it returns EAGAIN?). You should check return first, then if it indicates failure, only then look at errno.

captcha: xevious i hated that game

The real WTF is that he hasn't got any newline characters in what gets printed!

Jonathan:

You might [?] that this would prevent these forces from interacting with computers

You might what?

It's a madlib. I read it as "tapdance". "You might tapdance that this would prevent these forces from interacting with computers." Now it makes total sense.

That's no longer a pyramid! It can't work!

CrystalMethod:

This code is so naff, but my favourite is the belief that fprintf returns less than zero on error. fprintf returns the number of characters printed - on failure it sets errno.

... and returns a negative number. (see man fprintf)

john

I guess that the really real WTF is that I still don't understand why people try to catch some real WTF in what is obviously a really real WTF. To me, such a behavior is really a really real WTF, not just a real Really Worse Than Failure.

I'm not sure I'm clear.

Mcoder:

C has a lot of potential for bad code, but logging to stderr that it failed to log on stderr is really creative.

The potential for such a crock is there in any language, really.

Harry:

Duston:

I don't see where it logs "File Not Found"

If the log file is not found, how can you expect to see it?

The solution is to put it like this:

/* log("file not found"); */

Should work well (without producing any error).

Mcoder:

His reward was the understanding that error is set to 1 when any error occurs, not just file i/o errors.

Error is set on any error, the value depends on its kind and is probably not 1.

C has a lot of potential for bad code, but logging to stderr that it failed to log on stderr is really creative.

Is this an example of recursive error logging???

I am reading the Linux man page of fprintf(). It says: Upon successful return, these functions return the number of characters printed. If an output error is encountered, a negative value is returned.

What happpens if it is possible the write the first half, but there is an error with the second half, is undefined.

Volmarias:

snoofle:

So this is broken-register syndrome?

Sorry, is that an actual term? I can't find it anywhere, but it sounds interesting.

It's a hacker joke - the author of code that repeatedly does something stupid pretends that it's trying to avoid a "broken register" in the CPU, hence the multiple executions. It's probably in the Hacker's Dictionary / Jargon File unless that numbnuts Eric Raymond has changed it to something about how great guns are.

Kind of like locking your keys INSIDE to keep them safe.

At least he optimized the loop!

void LogError(char *error)

{

    if (fprintf(stderr,error)<0)

    {

        char fmt = "Error logging error '%s' to error log\n";

        char *s = malloc(strlen(fmt) + strlen(error));



        if (s == NULL)

            LogError("Error allocating memory to log an error logging an error; the error could not be logged\n");



        sprintf(s, fmt, error);



        // log the error

        LogError(s);



        // clean up after ourselves so that we never cause a massive memory leak

        free(s);

    }

}

<quote>
/* log("file not found"); */
</quote>

should definitely work well but we have to think of the gas machines from the steel factory

CrystalMethod:

This code is so naff, but my favourite is the belief that fprintf returns less than zero on error. fprintf returns the number of characters printed - on failure it sets errno.

captcha: I'm not telling you

This is not true. If the printf() family of functions has internal errors, then they return a negative value. Sometimes, they print less than the intended amount, and the return value is the truncated number of characters.

In any case, the system has crashed when stderr stream is not available.

As soon as I saw this I said "Worse Than Failure!!!". Oh, no, I guess not - I probably said "What the F***".

Yeah, except that it's not a joke. One chip in the one of HW platforms I've worked on had a bug where writes to a particular register would fail somewhere between 1% and 10% of the time, completely at random. The failure to set this register correctly wasn't awful, but a temporary loss of functionality.

What made it worse was that it was a register that we wrote to to invoke some processing on the chip, and the first thing the chip would do would be to clear the register, so we couldn't read it back. Fortunately, writing the register multiple times was completely safe, so we worked around it by writing six times in a row.

The explanation for this behavior was very well commented.

I'm not sure what language you're using, but in C fprintf returns a negative value if an output or encoding error occurred (ANSI ISO IEC 9899-1999 7.19.6.1 paragraph 14

The "guru" must really want to make sure it failed. The C libs really leave room for obfuscation.

if (error)
if (fprintf(stderr,"All work and no play makes Jack a dull boy")<0){
if (fprintf(stderr,"all Work And No Play Makes jack A Dull Boy")<0){
if (fprintf(stderr,"All work")<0 && fprintf(stderr,"no Play Makes jack A Dull Boy")<0){
if (fprintf(stderr,"All work")<0 && !fprintf(stderr,"Play Makes jack A Dull Boy")<0){
return fprintf(stderr, "An error occured while writing to stderr");
/* lets stop here, its enough */
}
}
}
}

Rich:

on failure it sets errno.

Technically true, but one could read this to say you don't need to check return values, just check errno. errno could be set on any subfunction calls (maybe i'm writing to a socket, and it returns EAGAIN?). You should check return first, then if it indicates failure, only then look at errno.

In fact, I'm not even sure if just checking errno is valid. I'm under the impression that if a function succeeds what it does to errno is undefined, so you can't rely on it being a specific value when it comes out. It could set errno when it succeeds in other words.

Ignoring practical concerns about if this would ever happen in real code (I'm an academic ;-)), am I right about this? It's been a while.

I call BS. This kind of monstrosity could only have been created in VB, because all C/C++/C# developers write amazingly tight, readable & otherwise immaculate code. :p

Jeff

snoofle:

In my military-subcontractor days, I once saw someone actually do something like this (on a system that could run interactively, or as a headless daemon):

// paraphrasing...

try {

    // ...

} catch (Exception e) {

  try {

      // write error to message queue

  } catch (MessageQueueException mqe) {

    try {

        // write error to message log

    } catch (IOException ioe) {

      // log file not accessible

      try {

          // print to stderr

      } catch (Throwable t1) {

        // Someone closed 2: might be running as daemon

        try {

            // print to stdout

        } catch (Throwable t2) {

          // Someone closed 1: might be running as daemon

          // intentionally do a divide-by-zero error

          // to force underlying system to puke

        }

      }

    }

  }

}

I've seen something similar, though not identical. The lead programmer was a true font of WTFs; among them was his invention of his own logging system. Every logging call could throw an exception, so he often had code like this:

try {

  myBrillantLogger.log("Something failed");

} catch (Exception e) {

  try {

    myBrillantLogger.log("Something failed");

  } catch (Exception e) {

    try {

      myBrillantLogger.log("Something failed");

    } catch (Exception e) {

      try {

        myBrillantLogger.log("Something failed");

      } catch (Exception e) {

        // I'm not sure what do.  Can't do this forever, right?

      }

    }

  }

}

We used to gather 'round a monitor and snicker when he wasn't around.

This code truly is enlightened! The output of fprintf(stderr,"An error occured while writing to stderr") is 42.

CrystalMethod:

This code is so naff, but my favourite is the belief that fprintf returns less than zero on error. fprintf returns the number of characters printed - on failure it sets errno.

Actually, a negative value must be returned if there is an output or encoding error. The only way you'd get zero returned is if your input string actually specified no characters, eg. fprintf(fp, "%s", "");

(Otherwise the system does not conform to the C standard).

Also, whether or not errno is set is up to the individual system, you certainly should not write code that relies on it to detect success or failure.

At least the code was well indented, well commented and easy to read!:-)