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: Greg Hurrell <email@hidden>
- Date: Tue, 16 May 2006 12:59:21 +0200
El 16/05/2006, a las 8:16, Lon Giese escribió:
Lots of good suggestions, I hadn't thought of spawning a child
process to parse the files...
The stack trace is good... I need to implement that.
trapping the signals should be standard for any first class app
An alternative view point on catching signals:
I don't trap signals because if there's a bug in my code then I
actually *want* it to crash. Rather than continue running in
unpredictable and undefined ways I'd rather that the app die and my
users can then send me a crash report. "But crashes look really bad
to users!", you might say; I'd rather have a crash which I can then
fix than have a program that *appears* to work when in reality it's
not doing what you think it's doing.
In general, reproducible crashes are much easier to find and fix that
nebulous, vague bugs that don't lead to crashes but do lead to subtly
unexpected or undefined behaviour. For the same reason I pepper my
code with lots of assertions; if things aren't working as I expect
them to I want to know about it.
In the case of the example you're talking about (a corrupt or
maliciously crafted input file), the bug is that the program doesn't
do sufficient validation on the supplied data before working with it.
"But it's not a bug in my code! It's not my fault that I was passed
bad data!", you might say; the truth is that it is a bug because
failing to perform input validation *is* a bug. Basically anything
that is produced from outside the boundary of your program falls
outside the "circle of trust" and therefore has to be sanitized/
validated before use. This includes *anything* read from the disk
(even stuff like preferences files) or from the network, and any
input supplied by the user. The only data you can actually trust is
data that you yourself produced from within the application. Even
then such data could case a crash if the data was produced using
buggy code (and if it crashes, good, because that will draw your
attention to the bug and you can then fix it!).
If you get a SIGBUS/SIGSEGV there's no real way for you to
distinguish between "harmless" (recoverable) errors and "harmful"
ones, so the conservative policy is to treat all such signals as
fatal and try to identify the bug that's responsible for them.
Basically, the best way to "catch" such signals is to eliminate their
causes, not try to intercept them at runtime.
Cheers,
Greg
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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