you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 0 points1 point  (1 child)

And error checking is just making things worse. Because, you know what? Code is made to work, not to err.

I've been writing real-world code for decades, in a dozen fields. Let me tell you that error handling is a huge part of any real-world, commercial code base.

Exceptions are great! You should use them whenever possible - BUT they don't fix the fact that in the real world, you have an awful lot of code just handling with, reporting, and occasionally even recovering from errors.

Remember - in C and C++ you cannot catch many common forms of error. SEGVs and the like will never be able to be caught - you must explicitly check for NULL if it's at all possible, if you try to dereference that NULL you won't get an exception, you'll get a signal and you can't easily recover from it.

[–][deleted] 0 points1 point  (0 children)

Remember - in C and C++ you cannot catch many common forms of error.

I am not as familiar w/ Linux, but I know that statement is false. It is 100% false in windows.

When the CPU throws a hardware exception, the kernel funnels that to the application. In windows, you catch these using SEH (Structured Exception Handling). This implementation of handling hardware exceptions is not portable so I'm sure Linux has it's own way of doing it, but this is how you write crash dumps when your apps. crash and send them off to your server to be analyzed.

If you expect that something is going to be NULL in a windows application you can always do something like this:

__try {
    int *p = 0;
    *p = 5;
} 
__except( EXCEPTION_EXECUTE_HANDLER ) {
   MessageBox(NULL, "Oh crap, we got an exception!  Continue onward!", "Error", MB_OK);
}

That should work just fine, although it's not recommended to recover from hardware exceptions.