I use a lot of R, and like many aspects of it. But the fact that `f(stop("Hi!"))` may or may not throw an error depending on the internals of `f` is a little maddening. (And there are tons of similar issues.)
I mean compared to other languages these sorts of quirks might seem like big deals, but they rarely come up. You see that error, you copy paste and find a stack overflow thread explaining it, you know what to do next time and move on. R is certainly no C.
Someone can fix this by creating and popularizing a simple preprocessor that implements a macro called "safely" that expands to something like "call this function, and then if it errors, report the error to STDERR and abort execution". Then just prefix the majority of your commands with "safely", and implement your own error-handling in the few cases where you care.
i took a brief look at the csv module (i know quite a bit about csv - authpr of the csvfix tool) and i would observe one general point. the error handling is terrible. functions either call exit() on an error, or simply print an error message and carry on as if nothing was wrong. i know error handling in C is difficult (one reason i prefer C++) but we can do better than this.
another general point is that almost all the functions return void. this means that they must have side-effects. i am very far from being an FP maniac, but i do like a bit of purity when i can get it.
also, some comments would be nice.
bottom line - not for me, but then i haven't written any C for over 30 years :-)
Sometimes those aren't so great. For example, C has errno, a thread-local variable that gets set to the error code of the last function you called. Why can't the function just return the error code? I think it's strange how all the Linux system calls do return error codes but the standard library puts them in errno anyway.
I really like writing freestanding C because I can avoid most of the legacy.
It's only broken if you don't get the joke. Asking someone to review and merge a patch for strfry() is, if not unreasonable, then at least something that's reasonable to say "no" to.
So what you mean to say is that the problem is not so much that there isn't any error reporting, but that, in C, it's being ignored ?
Never do
printf("here's a number: %d", 11);
Always do:
int attempts = 0
int ret = printf("here's a number: %d", 11);
while (attempts++ < max_attempts && ret < 0) {
switch (ret) {
case EINTR:
case EAGAIN:
ret = printf("here's a number: %d", 11);
default:
// At this point you, as a programmer, should STOP AND THINK.
// What would be a reasonable reaction here ? How will it affect
// everything else the program does ? What is the correct way to
// proceed ?
//
// P.S. Anyone doing "return -1;" at this point should be taken out and shot.
// and yes, that's the C equivalent of what every Go programmer always does.
panic("printf error", ret); // for example, crash the program.
}
}
Needless to say, you should do this on EVERY printf statement.
There. Isn't explicit erroring great ? NO IT ISN'T.
Needless to say, this has an almost direct translation to Go. Does anyone do this ? Of course not. In Go, like in C, like in shell scripting, in the vast majority of programs nearly all errors are ignored.
That's why exceptions are so very superior to explicit error handling : it accomplishes many things :
1) it alerts the user that an error occured. "Explicit error handling" like C, Go, most C++, ... do will simply silently attempt to proceed, likely turning a small error or a typo into a disaster or catastrophe. Silent database corruption, here we come !
2) It provides information about where the error occured. Stop me if this sounds familiar: "when an error is printed, and the program crashes, I download the source and grep it for what I think is a unique word in the error message. When it turns out it isn't I get cranky. When it turns out there isn't a unique word in the error I just sit down in a quiet corner and softly cry".
3) It allows for "layered" error management strategies. I'm not saying it gets it up to OCaml levels, but it is far superior to C or Go error management. In the main function, you catch any Exception for the various parts of the program you start, log it in a reasonable manner, alert if necessary, and restart the relevant portion of the program. Inside the parts of the program you catch finer grained exceptions with more explicit management.
4) it's far more concise.
So "explicit" error management ? Let's just be truthful here (just look at Github examples of C and Go code): it's really just ignoring errors.
You can find coding errors involving ignored errors in the Go standard library in minutes. Examples:
Enjoyable read for sure, but i think the question whether ot not this constitutes a bug or not is open for interpretation.
IMHO, it doesn't.
hello.c is written in a way that makes it very clear that the program doesn't care about error conditions in any way shape or form; the return value of printf is ignored, the output isn't flushed, the return of flushing isn't checked, noone looks at errno; ...so anything happening that could go wrong will go unreported, unless its something the OS can see (segfault, permission, etc.)
If I expect a program to do something (eg. handle IO errors) that its code says very clearly that it doesn't, that's not the programs fault.
On reflection, I think C is a language where this kind of error is less likely. In languages where it's easy to cram strings together and parse the results, people are more likely to do it. Those things are a bit of a pain in C, so people are more likely to do things another (and in this case better) way. Of course, that was obviously no guarantee.
C is not a holy cow, is it? It's just a very, very popular language. Error handling is important in programming in general, and having ways to implement it conveniently helps a lot.
Yes, errors are just data. And everything is data, including the code itself, right? It a question of abstractions introduced to the language and the program at question.
errno.h is bad. It's inconvenient, it's global, even if it's a thread-local something, it's cumbersome to use.
AFAIK, there are 2 error-related proposals for inclusion. One is making errors special, the other is a bit more generic. Both would improve on the current situation.
Similarly python throws an exception, and I bet other languages have their own behaviors, but in case of C this is the only way (or at least it is the only non complicated way to do it).
When I read this article I thought it was preaching to a choir. I'm actually quite surprised people programming C don't check for errors. That's the only way the functions can provide a feedback.
reply