[prev] [thread] [next] [lurker] [Date index for 2007/01/28]
Peter da Silva wrote: > Back when I was a young programmer, error handling was done by > explicitly passing status back up the call chain. You always checked the > error status of every call, and handled it or aborted *right there* with > the proximate error cause if you couldn't. It is done this way today quite often, say in embedded applications or in projects where the project leader has been burnt by exceptions in previous projects. The problem is that a lot of calling code *doesn't* bother to check the status. People don't like to do that, especially when they can't abort right there and must propagate status up the call chain, so they deny the existence of errors. And sometimes they don't even know there's an "exit status" (because of not being fully aware of errno, herrno and the like). And sometimes they clobber the status (with things like sqrt(-1) + sqrt(4)). A special place in my heart is reserved to wankers who add an error status to all their functions and then always return OK/handle errors of the stupid kind, like checking if the enum value I pass really belongs to the enum. People tend to ignore the exit status of this kind, including the one case in a hundred where the wanker's library actually detects an error. > > It took me a long time to accept the throw/catch model for errors was > even acceptable in theory, since you obviously would never be able to > actually *handle* any of the failure modes properly... but at least it > would speed up coding by giving you well defined points where you could > abort with the status that you had dutifully passed back. I don't have a positive experience to cite when it comes to *recovering* from errors in complex cases. But if you need to *detect* errors, a call stack is better than "Is a directory" printed by hell knows what buried hell knows where. And you can do things like run a lot of test modules and save the points of failure easily. I don't like throw/catch in C++ because it slows down the entire body of code and because you *don't* get a call stack (so even abort() with a core dump is better than throw) and because I don't like anything in C++. But in a managed environment, I think I like exceptions, unless it's a huge bulk of code with very hairy failure modes, in which case I don't know. > > It didn't take me long to realize I was fooling myself. Particularly > when you have buggers throwing the *wrong* exception upstream so you > can't ever do the right thing. It's no wonder that most people don't > even try. > > These buggers can fairly easily pass the wrong error code upstream (or, more frequently, pass less and less specific error codes until you end up with "hmm, something is wrong somewhere" at the top level). If someone has a serious wetware problem, there is no software fix for it. That someone will fuck things up with exceptions and with error codes and with anything. Exceptions and error codes aside, people who trap SIGSEGV should be shot.There's stuff above here
Generated at 23:01 on 06 Feb 2007 by mariachi 0.52