Fwd: More Mac like handling of OS raised exceptions
Fwd: More Mac like handling of OS raised exceptions
- Subject: Fwd: More Mac like handling of OS raised exceptions
- From: Lon Giese <email@hidden>
- Date: Tue, 16 May 2006 10:46:45 -0700
Sorry, mail keeps replying to the individual who wrote the email
instead of the list. I have to remember to change the reply to
address....
Begin forwarded message:
From: Lon Giese <email@hidden>
Date: May 16, 2006 10:42:17 AM PDT
To: "Shawn Erickson" <email@hidden>
Subject: Re: More Mac like handling of OS raised exceptions
Let me clarify a couple items
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...
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... And these
files! I never seen such over engineered stuff, one is a three
dimensional array and the dimensions intersect each other! and
contains redundant information, and the info you need at one layer is
contained in the layer above or below! the only way to read it is to
traverse the file byte by byte... You simply cant read a nice little
index that tells you all the item counts, offsets and sizes and then
calculate a neat little integrity test... The fastest way to code
this is to bracket it with an exception handler. Thats what I was
hoping to do. Instead of coding really cool features I have write a
ton of code to keep the kernel happy...
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,
AND this is a big big big AND the kernel CANNOT detect when your
process overruns one variable and clobbers another variable if both
are within your owned memory space. Consequently, no signal is
generated and your app goes on its merry way saving corrupted data and
feeding bad info to the user... where's the kernel now when you really
need it? in a blocked thread sleeping, he doesn't give a hoot if you
clobber your own memory.
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...
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).
On May 16, 2006, at 8:33 AM, Shawn Erickson wrote:
On 5/16/06, Ondra Cada <email@hidden> wrote:
Shawn,
On 16.5.2006, at 16:39, Shawn Erickson wrote:
>>> The stack trace is good... I need to implement that.
>
> The easy and quickest thing to do is to ask your customers to send
> you the crash logs if your application crashes. They will be
> generated automatically by CrashReporter and easily located by
> customers. ...in other words nothing to implement.
>
> Review... <http://developer.apple.com/technotes/tn2004/tn2123.html>
Well.... it can be worthwhile to scan for a crash report when the
application launches, and if some are found, to ask the user whether
they can be sent home (and if he approves, do that programmatically).
Although it is really easy to send the reports, in my experience,
*lotta* users don't care. (Well in a sense they are right: they are
*users* after all, not betatesters ;))
Well in the context of OP he appears to be talking about alpha/beta
testers. You can/should/require those folks to send you such
information and detail feedback IMHO or you are wasting your time (and
theirs) with the alpha/beta test.
-Shawn
_______________________________________________
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