1

in view of this and this, here is my strategy(similar to win32 api functions) :

1)Reserve return value for indicating success(non zero value),error(0).

2)use errno,perror to give more info. on the type of error.

3)use parameters to return values.

If this is OK then can I define my own error codes(not conflicting with the existing codes) and use errno to set/retrieve them. I don't think now I would be able to use perror with these codes(it will always say:unknown error) but I can define my own switch case based function to return description of the error code.I could define my own variable but much has already been done to make errno modern and thread safe.

eg:

int val;
if(MyPop(&val))
   pintf_s("\n %d popped from my stack. . .",val);
else
   printf_s(Myperror());

Thanks.

Community
  • 1
  • 1
rsjethani
  • 2,179
  • 6
  • 24
  • 30
  • 1
    what is your question exactly? – Mat Jun 22 '11 at 10:10
  • @Mat I want to know whether using perror is thread safe way or even is it a good error handling strategy?I would also like to ask you the same Qs that I asked David in a comment below.Please give your opinion. – rsjethani Jun 22 '11 at 12:03

1 Answers1

5

I don't think anyone nowadays would design an error handling system like errno. Even if errno is implemented using thread-local storage it is still far from ideal—it is still a global variable at heart.

Since you don't have grown up error handling based on exceptions I would recommend returning error codes as function return values. This allows you to use the stack, avoid global state, and therefore be resilient to threads and re-entrant calling patterns.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
  • 1
    If using errno mechanism is 'outdated' then why the api still uses it?also wouldn't it be harder to write a func returning say 5 error codes? – rsjethani Jun 22 '11 at 10:53
  • I agree, that's a principle I try to use as often as possible: always return an error code and pass the result variable as an argument: `errcode getSize( int *size )`. This way you don't have to use magic values to see that the function has failed, and you have thread-safety within. – Gui13 Jun 22 '11 at 10:53
  • The C standard library and the Windows API were designed a very long time ago. The design can't be changed now because that would break compatibility. It is not a good model on which to base new designs on. Most of my time with the Windows API is spent wrapping it up so that the real code that I write is not exposed to the gory messy details. – David Heffernan Jun 22 '11 at 10:59
  • @David:Whats your view on using setjmp/longjmp,signal,assert strategies?Should they be used today or not?What would be your strategies if wanted to write bulletproof commercial c code:In terms of end user,future modifications blah blah...?? – rsjethani Jun 22 '11 at 11:07
  • `setjmp/longjmp` can very easily lead you into resource leaks because tidy up code is skipped. I personally would avoid writing C code at all costs and use a higher level language. – David Heffernan Jun 22 '11 at 11:28
  • 1
    @David:when dealing with low level details, I don't think there's any other alternative... – rsjethani Jun 22 '11 at 11:56
  • @ryan Sure there is. You show me a problem that can only be solved in C? On the flip side this question is highlighting one of the great problems with C, no support for threads and error handling. – David Heffernan Jun 22 '11 at 12:33
  • @DavidHeffernan **`You show me a problem that can only be solved in C?`** Program an embedded system, where only C compiler is available? Develop a C library? Contribute to open-source operating system like Linux? – mip Jan 25 '17 at 15:31
  • @doc Obviously if you constrain the question to C, then clearly it can only be done in C. – David Heffernan Jan 25 '17 at 15:43
  • @DavidHeffernan isn't the question constrained to C? We have a thing called tags to constrain questions even more, you know... I'm also affraid that it's neither me nor OP, who impose constraints, so that some embedded systems have only C compiler available, or that Linux has been implemented in C... – mip Jan 27 '17 at 13:48
  • I was speaking more generally than those narrow constraints. Read the thread again. – David Heffernan Jan 27 '17 at 13:54
  • @DavidHeffernan than which narrow constraints? I'm answering your comment on showing problems, which can be solved only with C. There are such problems and it's not a matter of preference, like your comment seems to suggest. – mip Jan 27 '17 at 14:05
  • @DavidHeffernan I also dislike the mantra "avoid C at all cost". The correct approach is to pick right tool for the particular problem. There are domains, where you would use an assembly language to satisfy your needs, so don't make such statements. – mip Jan 27 '17 at 14:12
  • That's not at all what I meant, but I don't really want to argue with you. I don't think you understood the point I was trying to make, but 6 years on I'm not really interested in this discussion. Let's leave it at that. – David Heffernan Jan 27 '17 at 14:16