Ghosts of Unix past, part 3: returning -1 for system call failure

Posted Nov 19, 2010 23:48 UTC (Fri) by giraffedata (guest, #1954)
In reply to: Ghosts of Unix past, part 3: returning -1 for system call failure by jhhaller
Parent article: Ghosts of Unix past, part 3: Unfixable designs

I don't know if it was an accident due to PDP-11 praticality or just good design philosophy, but I very much appreciate the convention in Unix of not returning information when a system call fails. I.e. a failure is a failure. If you get back useful information, or the system changes state, it's not a failure, but a different kind of success.

So I guess you're saying if a read of 10 sectors fails due to a media error on the 5th sector, you'd like to see the result, "failed due to media error, but read the first 4 sectors." I like Unix'es version much better: Instead of requesting 10 sectors, you request "up to 10 sectors" and it succeeds with "4 sectors read" and the next read truly fails.

Things that fail but don't fail are much harder to program to. They engender mistakes and convoluted code. "Failure" has the special implication that you can probably just stop thinking about it and give up on whatever you were doing. They are the inspiration for exception throwing in programming languages.