Hacker News Reader

Comment by jwilliams | Hacker News Reader

The thing about C is that you are generally very aware of the side effects. Aside from the libraries you use, the (data) structures are yours. When you set something to NULL, you know damn well that that means to you.

As the author alludes to as well - in C you're made more aware of the error conditions you can handle and the ones you can't. So you can code to a level of robustness... Exceptions in Java are all well and good, but I haven't seen many implementations that do anything with IOException except for cascade it.

This works really well for programs/modules that can fit in the head of a single programmer. When you go beyond that it gets pretty messy - which is where some of the advantages of metaphors like OO start to help... Course, there is the argument that modules should never get that big, but that's another debate.

View on HN

"As the author alludes to as well - in C you're made more aware of the error conditions you can handle and the ones you can't."

You mean like when a function silently returns -1 to indicate failure and then you wonder why your program returned a wrong result (if you're lucky enough to even notice)? In the bigger part of most of my programs I want a big, flashy, loud, total failure by default if anything goes wrong.

The only time a function would "silently" return a -1 would be if you're not checking your returns for errors! Functions have return codes for a reason.

But oftentimes I want a correct result or an obvious failure, without having to handle tons of errors I don't even want to account for.

Returning -1 is an obvious failure.

What you're saying is that you want your programs to blow up when a function returns a known error (such as "disk full").

One of the points of the article is that C makes you think about all the possible, well-documented, errors that each function can encounter. You know when you write C precisely what can go wrong at each stage, and decide the right way to handle it.

Seeing a dialog box pop up with some exception backtrace is one of the things that annoys me about 'modern' Java-esque languages: they seem to encourage developers to default to ignoring most exceptions.

Defensive programming vs. `Let it fail`.

I think the space between to two is more uncomfortable than either extreme.

Interestingly, I noticed earlier this week that the new GCC gives warnings when the return values of POSIX / libc functions are ignored but shouldn't be.

Which versions of gcc and libc? Any special flags passed to gcc? I ask because I just tried it with a test program here (openSUSE Factory, gcc 4.3.3 and glibc 2.8.90) and it didn't print any warnings, but it would be nice if it did.

The difference between letting an exception bubble up and seeing a system call fail and aborting is pretty small. Either way, you need a higher level way of dealing with it.

One of the most interesting papers I read was "Why computers fail and what we can do about it" by Jim Gray while he was at Tandem. Transactions are essential, and most failures are transient. This can be applied at many levels, and can deal with many failures without the developer of the mainline code having to decide what to do for each given failure.

Exactly. In properly written C, about half your code is checking for errors and handling them explicitly. If you don't do that, at some point it will blow your foot off; you have to account for those errors. C programmers have generally accepted this and thus spend an excessive amount of coding time thinking about and writing recovery mechanisms for external errors -- and that's why so many C programs are incredibly stable.

Yes.

  if ((result = foo()) == -1) {
     fprintf(stderr, "!$*!$&^!$*!!!!\n");
     exit(1);
  }

That won't scale. I'm sure you'll have lots of fun grepping through your source files looking for "!$!$&^!$!!!!" when it appears on your stderr. The point is that with an exception system you don't have to write stupid shit like that everywhere just to crash and burn correctly.

Failing loudly is the only sensible behavior when an unexpected error occurs and there's absolutely no indication of what to do in such a case.

This is why assert exists.

tyger(~)% cat << EOF > main.c

? #include <assert.h>

? void main( void )

? {

? assert( 0 == 1 ) ;

? }

? EOF

tyger(~)% gcc main.c

main.c: In function ‘main’:

main.c:4: warning: return type of ‘main’ is not ‘int’

tyger(~)% ./a.out

Assertion failed: (0 == 1), function main, file main.c, line 5.

Abort

tyger(~)%

From what breif comments I've read on Lisp's condition system, it sounds much better. Containing and isolating the error, as soon as possible, then passing information about the error higher up like an exception might propagate, until a level high enough to know the goal of the operation and what to do in case of errors, then passing a response back down, and being able to continue in a useful manner or tidy up gracefully.

A great big codesplosion spraying you with a several hundred lines of stack trace and a "Your program has encountered an error an needs to close" is not "sensible behaviour".

"A great big codesplosion spraying you with a several hundred lines of stack trace and a "Your program has encountered an error an needs to close" is not "sensible behaviour"."

Yes it is, if it's a program in development where I haven't yet decided what behavior an error condition should produce.

You guys don't seem to understand I don't necessarily want to decide how to handle all errors now, not that I never want to have to think about how to handle them.

If exit() is too abrupt, you can always use setjmp() and longjmp() to set up a non-local jump to an error handler.

setjmp/longjmp is essentially what exception handlers do for you. I love C for its simplicity, but I'm not certain that leaving exception handling out of the language was a good idea. There are a lot of people who would agree with me there, including (I believe) a few Bell labs veterans who wrote the language in the first place.

The nice thing about exceptions beyond setjmp/lngjmp (in C++ at least) is the destructor semantics which you can use to guarantee that resources are cleaned up on error. There are better ways to handle such things, such as scoped resource allocation, but exceptions do an ok job.

You can actually use setjmp()/longjmp() to implement that kind of thing, it turns out. Here's but one example:

http://www.on-time.com/ddj0011.htm

I'm almost tempted to make an analogy with scheme's (call-with-current-continuation) here, but I think that might be pushing it.

Agreed. I rarely exit() out of an error. I was responding to the parent's want for "a big, flashy, loud, total failure".

You mean like when a function silently returns -1 to indicate failure and then you wonder why your program returned a wrong result (if you're lucky enough to even notice)?

This is the fault of the programmer who wrote the function, not of the language.

What? What can a programmer do besides returning a "special" value such as -1 in a language like C with strict types and that doesn't support exceptions?

You don't need an exception mechanism to deal with this - good libraries will let you find out the exact condition (if you do get a -1 for example).

By the same token, dozens of Java libraries only throw ABCException, with no other information... Might as well be -1.

But you can't ignore the ABCException, your app will crash. If you ignore the -1, then you're app will happily continue on doing something wrong.

Sure you can ignore it. You don't want to know the number of times I've seen people using the "try, catch, toss away the exception" structure in Java code.

But you have to actively decide to ignore it.

Whereas when you're dealing with return codes, the default is to ignore.

In OCaml, you're required to do something with the return from any non-void function. You can just say "ignore (f x)" to discard the result, so it's not hugely inconvenient, but causes suspect code to accumulate warning signs.

It seems like a good compromise.

This also seems like a pretty good strategy. I really need to take that OCaml book off the shelf.

Well I don't know your experience, but most Java developers I've seen either throw the exception, or suppress it... If they throw it, it eventually ends up as ABCGenericException and you've probably got no chance to reasonably recover. If you suppress it you end up with a nasty side effect (a null somewhere perhaps) that causes the app to bomb in another unexpected piece of code.

Exceptions are a language semantic - in itself it doesn't make your code robust. You still need to apply it correctly.

But! The reality is the same applies to C too. What the original author was alluding to what that the mentality of C encourages coders to look deeper into their errors.

False. In languages with better type systems (e.g. ML and Haskell), you generally use the "Option" (OCaml) or "Maybe" (Haskell) type in situations like these.

(Example code is OCaml)

  type 'a checked = Pass of 'a | Fail
  
  (* very much a toy example *)
  let even x = (x mod 2 == 0)
  let can_fail x = match x with
    | 0 -> Fail
    | x when (even x) -> Pass (x * 10)
    | x -> Pass (x)
  
  # can_fail 2;;
  - : int checked = Pass 20
  # can_fail 3;;
  - : int checked = Pass 3
  # can_fail 0;;
  - : int checked = Fail
  #

The languages infers where you're passing around option types (such as "int checked" above) and forces the calling function to account for any potential failures. Rather than just Pass 'a and Fail, it could be Pass, File_Not_Found, Access_Denied, etc., and (Unknown_Error string). OCaml also has exceptions, but the combination of union types and required exhaustive matching covers most cases.

Reply on news.ycombinator.com