need help on error handling.

Hi, I need some serious suggestions about error handling in C. Can some one please tell me of a better method to handle errors in my project. I will just post some code that I have written:

Code:

---

int init_plwave(void)
{
  int flag = 0;
  double theta, phi;
  double freq;
  double e0;
  unsigned long nrays;

  printf("Enter the number of rays\n");
  if(scanf("%lu", &nrays) != 1)
  {
    fprintf(stderr, "Error while reading the number of rays\n");
    flag = 1;
    return flag;
  }

  printf("Enter the frequency of the rays\n");
  if(scanf("%le", &freq) != 1)
  {
    fprintf(stderr, "Error while reading the frequency of the plane wave\n");
    flag = 1;
    return flag;
  }
 
  printf("Enter the direction(theta, phi) for the rays\n");
  if(scanf("%lf %lf", &theta, &phi) != 2)
  {
    fprintf(stderr, "Error while reading the direction for the rays\n");
    flag = 1;
    return flag;
  }

  printf("Enter the source electric field\n");
  if(scanf("%lf", &e0) != 1)
  {
    fprintf(stderr, "Error while reading the source electric field\n");
    flag = 1;
    return flag;
  }
  return flag;
}

int read_mesh(char *fname, mesh **m)
{
  FILE *fp;
  int flag = 0;

  fp = fopen(fname, "r");
  if(fp == NULL)
  {
    fprintf(stderr, "Error while opening file %s\n", fname);
    flag = 1;
    return flag;
  }

  *m = malloc(sizeof(mesh));
  if(*m == NULL)
  {
    fprintf(stderr, "Couldn't allocate memory for the mesh\n");
    flag = 1;
    return flag;
  }

  if(parse_zeus_file(fp, m))
  {
    flag = 1;
    return flag;
  }

  return flag;
}

---

Although, I do not feel there is anything wrong with this approach of checking for the error condition and then using fprintf to print errors, return some flag and terminate the function but as you can all see it is extremely verbose, repetitive and it looks as if there is hardly any code but only error handling in the program. Looks really ugly and gives a bad impression. I need some idea on a centralized error handling appraoch or atleast some suggestions on improving my technique. please help me.

Ah pet peeve of mine :)
Rather than checking whether the function returns a non_zero rcode, assign the return value of the function to a variable (called rcode or something) and test that. Then your printf statement can print out what the error was.
Then, instead of always returning 1, return a different code for each condition. The calling function should then print out that rcode and name of the function. This way, you basically get a stack trace of error codes and it will be very easy to pinpoint where the problem is.
Never use the same error message in two different places (I know you've not done that, but it's good practice).
If your code needs to abort because of an error (such as not being able to allocate enough memory), you don't need to set a flag and then return that flag. Just return the error code for that condition. If, however, you have a function that can soldier on, even when something has gone wrong, you can use flags to indicate at the end of the function that something went wrong, but it wasn't critical. You'd want to print something like "There was an error (code x), function_name recovered and terminated normally".

The reason your code looks verbose and ugly is because there is very little actual implementation code. Once you flesh out what you're doing, you'll see that in most cases the normal code far outweighs error handling.

Hope that helps,

QuantumPete

Quote:

---

Originally Posted by QuantumPete

Ah pet peeve of mine :)
Rather than checking whether the function returns a non_zero rcode, assign the return value of the function to a variable (called rcode or something) and test that. Then your printf statement can print out what the error was.
Then, instead of always returning 1, return a different code for each condition. The calling function should then print out that rcode and name of the function. This way, you basically get a stack trace of error codes and it will be very easy to pinpoint where the problem is.
Never use the same error message in two different places (I know you've not done that, but it's good practice).
If your code needs to abort because of an error (such as not being able to allocate enough memory), you don't need to set a flag and then return that flag. Just return the error code for that condition. If, however, you have a function that can soldier on, even when something has gone wrong, you can use flags to indicate at the end of the function that something went wrong, but it wasn't critical. You'd want to print something like "There was an error (code x), function_name recovered and terminated normally".

The reason your code looks verbose and ugly is because there is very little actual implementation code. Once you flesh out what you're doing, you'll see that in most cases the normal code far outweighs error handling.

Hope that helps,

QuantumPete

---

Do you think using __LINE__ , __FILE__ and __func__ macros can help ? For eg.

Code:

---

int something(void)
{
  double *b;
  int flag = 0;

  b = malloc(sizeof(double) * 500);
  if(b == NULL)
 {
    fprintf(stderr, "Memory allocation failure: module %s line %d function %s", __FILE__, __LINE__, __func__);
  flag = 1;
  return flag;
 }

  return flag;
}

---

Yes, that's a good thing in helping localize where the problem occurred.

Quote:

---

Originally Posted by Elysia

Yes, that's a good thing in helping localize where the problem occurred.

---

Is this really a debugging stratergy or error handling ?

It's more of debugging nature. It's priceless when shipping an app to someone else and it goes wrong somewhere.

Using assert() may be more useful to check conditionals.

Quote:

---

Originally Posted by slingerland3g

Using assert() may be more useful to check conditionals.

---

But assert will terminate the program.

assert is usually for programmer errors that are code errors, so to speak.
If it isn't - if something goes wrong, for example, then it usually is a better idea not to use assert.
assert is good for NULL pointers, for example.

I agree that, if this is for debugging, there are other means, but for simple error checking and allowing the user to either change their input and try again will be a better approach.

Is the intended purpose to have the program limp along for the user and latter crash?