3 ms·

"Sure, but their programs usually leak memory (ever use Firefox?), and their libraries handle errors by terminating the whole program (see PulseAudio; any error

by jey 18y ago

"Sure, but their programs usually leak memory (ever use Firefox?), and their libraries handle errors by terminating the whole program (see PulseAudio; any error condition immediately calls exit(1))." That's a poorly written program. You can just as easily System.exit(1) in Java, or to do it a more Javaesque way, throw new Error("im too lazy to do this right").

jrockway 18y ago
But C doesn't have any mechanism other than exiting or returning a value that indicates "false". Both are non-optimal. One (exit) makes the code simpler, but makes the consuming application extremely flaky; the other bloats the code with a weird API where functions modify their arguments: errorcode_t do_some_work(int arg1, int arg2, int *result) and forces the client code to check every single error and decide right then and there what to do. It's possible to write code that way, but why would you want to? This is a solved problem; why keep using a square wheel when round ones are available? (Yes, there is longjmp. Still a lot of work to use that square wheel.) In the end, don't think I care what programming language you use. It doesn't matter. But I do think that C should be dying off now; it is much less useful than it was 30 years ago.
- huhtenberg 18y ago
  > But C doesn't have any mechanism other than exiting or returning a value that indicates "false". Of course it does, in fact you just said it yourself - long jumps. Back in late 90s I worked with the firmware for the Point of Sale terminals, PIN pads, etc. It was written in C and its error handling was exception-based. Behind the scenes it was just a handful of long/setjmp wrappers, but it did nevertheless implement semantics of try/catch/etc. Additionally, "exiting or returning false" are not the only two options, nor they even the most commonly used ones. At least in the projects that I was exposed to. Kernel code (e.g. Linux, BSD) routinely uses int as a return value and it still somehow manages to be both readable and functional without being "bloated" or using "weird API". Yet another thing to consider is that optional exceptions (such as those in C++) come with a non-negligible performance hit, so it is considered an absolute no-no to use them in a "fast path" parts of the code. > But I do think that C should be dying off now But it just doesn't. Bummer :)
  - plinkplonk 18y ago
    "Of course it does, in fact you just said it yourself - long jumps. Back in late 90s I worked with the firmware for the Point of Sale terminals, PIN pads, etc. It was written in C and its error handling was exception-based. Behind the scenes it was just a handful of long/setjmp wrappers, but it did nevertheless implement semantics of try/catch/etc." David Hanson's book "C Interfaces and Implementations" explains how this is done and provides (very high quality) source code you can use/learn from.

by jey 18y ago

jrockway 18y ago

But C doesn't have any mechanism other than exiting or returning a value that indicates "false". Both are non-optimal. One (exit) makes the code simpler, but makes the consuming application extremely flaky; the other bloats the code with a weird API where functions modify their arguments: errorcode_t do_some_work(int arg1, int arg2, int *result) and forces the client code to check every single error and decide right then and there what to do. It's possible to write code that way, but why would you want to? This is a solved problem; why keep using a square wheel when round ones are available? (Yes, there is longjmp. Still a lot of work to use that square wheel.) In the end, don't think I care what programming language you use. It doesn't matter. But I do think that C should be dying off now; it is much less useful than it was 30 years ago.

huhtenberg 18y ago
> But C doesn't have any mechanism other than exiting or returning a value that indicates "false". Of course it does, in fact you just said it yourself - long jumps. Back in late 90s I worked with the firmware for the Point of Sale terminals, PIN pads, etc. It was written in C and its error handling was exception-based. Behind the scenes it was just a handful of long/setjmp wrappers, but it did nevertheless implement semantics of try/catch/etc. Additionally, "exiting or returning false" are not the only two options, nor they even the most commonly used ones. At least in the projects that I was exposed to. Kernel code (e.g. Linux, BSD) routinely uses int as a return value and it still somehow manages to be both readable and functional without being "bloated" or using "weird API". Yet another thing to consider is that optional exceptions (such as those in C++) come with a non-negligible performance hit, so it is considered an absolute no-no to use them in a "fast path" parts of the code. > But I do think that C should be dying off now But it just doesn't. Bummer :)
- plinkplonk 18y ago
  "Of course it does, in fact you just said it yourself - long jumps. Back in late 90s I worked with the firmware for the Point of Sale terminals, PIN pads, etc. It was written in C and its error handling was exception-based. Behind the scenes it was just a handful of long/setjmp wrappers, but it did nevertheless implement semantics of try/catch/etc." David Hanson's book "C Interfaces and Implementations" explains how this is done and provides (very high quality) source code you can use/learn from.