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: Kyle Sluder <email@hidden>
- Date: Mon, 19 Jan 2009 02:49:39 -0500
On Mon, Jan 19, 2009 at 2:32 AM, Graham Cox <email@hidden> wrote:
> 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).
Well it sounds like there are a number of issues here:
1) You're throwing exceptions in drawing code. Even if you catch them
so they don't screw up the draw stack, this will be extremely slow and
have adverse effects on the drawing.
2) You've gotten yourself into a situation in which you're trying to
meaningfully recover from an exception but you have to do it from a
place with outside of the exception's local context. This is why
Cocoa doesn't use exceptions for general circumstance; they're
notoriously hard to gracefully recover from.
3) You've over-architected your drawing code. Typically the fewer
objects that are responsible for drawing (i.e. view objects) the
better. Situations like the one you're describing often arise from
making model objects responsible for their own drawing.
> 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.
Cocoa exceptions are not supposed to be reached in shipped code (which
I'm sure you are aware). It also sounds like the view state is a
critical component of your app's model. This sounds like a Very Bad
Idea(TM).
> 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.
If it's possible to recover from the exception, have you considered
just fixing the situation, obliterating the graphics context, and
redrawing the view? Perhaps calling -[NSView renewGState] will make
your view usable again. Although this is dependent on separating your
model and view.
--Kyle Sluder
_______________________________________________
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