Re: Dealing with exceptions in a drawing stack
Re: Dealing with exceptions in a drawing stack
- Subject: Re: Dealing with exceptions in a drawing stack
- From: Graham Cox <email@hidden>
- Date: Mon, 19 Jan 2009 18:32:31 +1100
On 16 Jan 2009, at 8:33 pm, email@hidden wrote:
What are you doing that could throw an exception? After all,
exceptions are used to indicate programmer error, and are expensive to
throw. Something tells me that you shouldn't be worrying about
exceptions in your drawing code to begin with.
Sorry for not replying earlier - been away from the computer for a few
days well-earned break.
Naturally I would prefer that no exceptions can ever be thrown in this
code. But the reality of development is, that yes, sometimes they do.
Very often this is from an NSAssert message which are liberally used
throughout most of the code. They are there to catch occasional
mistakes on my part, and as such they do a good job. There are also
other situations such as calling an unimplemented method on an object
where the framework will throw. All of these situations are rare, and
when they do occur it's a trigger for a debugging session to track
them down, understand them and prevent them from happening again. The
drawing stack is potentially extremely complex, with many different
objects that can do drawing in an almost infinite number of
variations. (The number of possible combinations of drawing objects +
possible paths + drawing variations is deliberately enormous - far too
many to be able to test every one individually).
In many cases the unimplemented method (for example) is harmless, and
in final builds the asserts will go away. But nevertheless there
remains a very small probability that such an exception could arise in
shipped code - with the best will in the world I realise that I'm not
going to be able to ship bug-free code. Right now, the worst effect of
the exception is the bad state it leaves the drawing stack in, which
has a knock-on effect far worse than the original error. This loss of
the graphics state basically causes the user to lose all their data
(as it's a drawing app) whereas the original exception probably
amounted to very little and could largely have been ignored.
Thus I'd prefer the drawing stack to recover gracefully from
exceptions so that the user can continue using the app at the very
least to the point where they can save their data, and ideally such
that there is no detrimental effect at all. My belief is that that
would be a far better app than one that amplified the smallest bug
into an enormous one that pulls the whole thing over. An occasional
drawing glitch is forgivable, but not if it leaves the app unusable.
Also, if a user does run into an occasional drawing glitch, that's
what they'll see and hopefully it'll get reported as a bug that I'll
have some chance of fixing, whereas the whole document just going
blank and "acting weirdly" isn't going to help me in the slightest
track it down, since all I'll know is that it was due to an exception
somewhere down in my drawing code, which is probably 50% of the total
code.
--Graham
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden