Re: More Mac like handling of OS raised exceptions
Re: More Mac like handling of OS raised exceptions
- Subject: Re: More Mac like handling of OS raised exceptions
- From: Scott Ellsworth <email@hidden>
- Date: Tue, 16 May 2006 11:14:03 -0700
On May 16, 2006, at 10:46 AM, Lon Giese wrote:
I am a one man programmer on a project that is massive, truly
massive... So to cope I am using the 90-10 rule, 10% of your code
is executed 90% of the time... I realize I could check the
pointer is not out of bounds on every read and many languages do
just that like Basic, But 99.999% of reads are not out of bounds
so I am writing a lot of code that will almost never be executed
or almost never take the failed condition branch...
I have been a part of several projects like this, and I almost always
found good error handling to pay for itself in maintenance. If my
code did not crash, or at least warned me when it was about to do
something bad, then I was able to find and fix problems quickly.
The best approach, IMO, is to be suspicious of all external input,
and to put in the minimal tests needed at the lowest possible level
that can do the validation successfully. For example, instead of
trying to check the indices in a massive three d file, look at the
low level byte, string, or array reading code. Since that must fill
buffers with data, and it does it according to a count of bytes
requested, you can check that the buffer has enough room. Every
higher level construct will eventually call this lower level file
reading code.
If you ever find you are going to read sixteen bytes of data into a
buffer with only eight bytes left in it, the file has an error.
The interface is not that different - fread_check(*buffer,
*buffer_offset, buffer_size, file_handle, bytes_to_read), updating
the offset or returning the number of bytes read, however you want to
handle it.
It would be so much faster and easier If I could bracket all the
dangerous code so it calls a handler that can then let me recover,
call the file corrupt and go on to the the next one.
C-based languages, which Objective C is, allow you enough rope to
hang yourself. If you let a corrupt file write bad data to your
memory, then your app is dead dead dead, simple as that. To stop it,
make sure you do not write bad data to memory, by checking data
coming from untrusted sources.
Some languages with C lineage decided to fix that one way or
another. This is one of the things I like about Java - almost no
matter what bad thing I do, I cannot leak memory or crash the
program*. I can hold on to memory too long, and I can throw an
exception, but at least my internal variables are not corrupt.
Inconsistent, possibly, but not corrupt, and so I can track down the
state of my app using a debugger or memory profiler.
* of course, there are Errors, like OutOfMemory, that cannot be
easily handled. Not the best thought out part of Java, IMO.
I don't understand why a bad access signal is so intimidating,
modern personal computers have memory management hardware that
absolutely prevents access to any memory not owned by the process,
Right, but C decided, for performance reasons, that access to the
processes memory image is not something done under kernel control.
(mostly). ObjC inherits this - pointers in ObjC are real pointers,
not opaque memory handles like in Perl, Java, or Python.
So what happens is a completely harmless error terminates your app
and a fatal error goes undetected. Makes no common sense to me. I
don't like apps that crash and I don't expect my users to like it
either...
Which is why you write a reasonable amount of code to stop that. It
is not a ton, typically, though I admit I do prefer languages where I
do not have to write code like that at all. I would rather have a
language level exception propagate up to the handler, which can then
decide what to do about it.
And having them email me a crash report is not a good answer...
how many times has safari crashed on me? lots. I fill out the
crash report that is zipped to apple over the internet, never hear
a thing back and safari still crashes... crash reports don't do
apple much good either... (I'm not bagging safari, it is way
better then explorer).
Actually, those crash reports do help people able to interpret them.
If they do not help you, you might want to learn that skill. (Or not
- if your app does not crash often, then you might be better served
spending the time bulletproofing the app's external interface. You
learn the skills needed to handle the problems you actually have.)
That said, I find that time invested up front in preventing problems
will usually pay for itself in not having to track them down. That 90
10 rule another way - it takes a long time to find a memory bong
after the fact, and relatively little time to prevent it up front.
Scott
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden