Need advice...code structure for exit from error in c ?

hottdogg · 07-04-2008, 03:23 AM

just need a little bit advice for code flow design from experienced c/c++ programmer here...

If I want to terminate a program from error (let's say it's not a too complex program),
should I terminate the program from an error handling function(with possibly in different source file from
the function that invokes error handling function) OR go to error handling and then back to the current function and exit
program from the function itself ?

Tnx in advance

jailbait · 07-04-2008, 04:14 PM

One consideration is whether functions have to do any cleanup before exit such as close files and/or release dynamic memory. If so then you want to exit back up through the function chain in the same order that you came down through the functions. Or you need some sort of error cleanup routine.

-------------------
Steve Stites

Mr. C. · 07-04-2008, 04:47 PM

Why does one need to perform any file close or memory cleanups upon exit? This is done BY exit.

But jailbait's general point stands. You can create functions which exit within the functions, such as:

Code:

safe_open() {
   open file... or exit
}

main() {
  safe_open();
  ...
}

This method makes for cleaner code in many cases:

Or you can return error codes, and have your main code perform the exit:

Code:

my_open() {
  open file,
  return open return status, or your own error status
}

main() {
  if my_open fails
     exit
  ...
}

This form can litter code with lots of if blocks.

Really, it comes down to a matter of taste and desired affect.

jailbait · 07-04-2008, 05:08 PM

Quote:

Originally Posted by Mr. C.

Why does one need to perform any file close or memory cleanups upon exit? This is done BY exit.

This is true when you are running an application program which exits to an operating system. It may or may not be true when you are running a transaction which exits to middleware.

------------------
Steve Stites

Mr. C. · 07-04-2008, 06:16 PM

I suppose "terminate the program" is satisfying enough for me that the OP is talking about a basic, good ol' fashion POSIX or similar binary that exits to the OS via _exit(). Typically such a question like this is from a new programmer, learning the basics, and not programming some fringe environment.

But you're right, there can be all sorts of variants.

jiml8 · 07-04-2008, 10:12 PM

Proper procedure is to assume your OS will NOT clean up after you, and just do it. This way, if anything unexpected happens you are cleaned up anyway.

Mr. C. · 07-04-2008, 10:22 PM

Oh, that's nonsense.

The kernel returns free pages back to the pool upon process exit.
The _exit() call closes all file descriptors
All memory is freed and returned to the free pool on exit.

This is all part of the C runtime, and standard kernel process management.

jiml8 · 07-05-2008, 01:49 AM

Lazy programmers don't do garbage collection, depending on the OS to do it for them.

Then, when their code is used in an environment other than that for which it was originally written, it leads to memory leaks.

If you work for me, you'll do garbage collection. If you refuse, or if you insist it is nonsense, you won't work for me.

Mr. C. · 07-05-2008, 02:50 AM

[ Note: in general, I'm in complete agreement with your belief in good programming practices and demands of your empolyees ]

What is nonsense is the single-minded policy. We need to teach when/where/how to think and learn, not to mindlessly follow dogmatic rule, all the while not having a clue as to what is going on.

You do rely on the OS to do its job - or it would come to a screeching halt fairly quickly.

I doubt you close FD 0-2 before you call exit. In fact, you'd have to check first to see if they were even open! You don't reset your brk. You probably don't call flush before a close. These are things you must rely on from the system at hand.

There is no need to free malloc'd space in essentially linear, simple programs where the C runtime guarantees cleanup. How do you do garbage collection in a language like Perl? You can destroy, but beyond that, its op to the interpreter and OS to *do their job*. I'm sure you don't do SV cleanup. In kernel development, or microcode, you are concerned about every byte. In higher level languages, we let the OS and runtime environment take care of many things.

It is not about laziness. It is about knowing when and how the tools, environment, and systems work, and what is ***guaranteed*** and what is not.

Adding superfluous code increases risk, increases code coverage requirements, increases complexity. The pitfalls of an errant free() are problematic.

I'm fully aware of the requirements to manage resources and cleanup when and where necessary; I'm also fully aware of when and where it is unnecessary. I feel this is more important to teach than mindless, one-size-fits-all rules. We need to teach why, not do as I say or I'll fire you. Knowledge impresses, threats are for children.