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: Paul Bruneau <email@hidden>
- Date: Mon, 19 Jan 2009 14:15:25 -0500
On Jan 19, 2009, at 2:08 PM, Quincey Morris wrote:
I don't get this at all (not just the quoted comments, but going all
the way back to Graham's original statement).
-- If a failure in the drawing code destroys the *data model*
(thereby preventing it from being saved) then there's something
terribly wrong with the drawing code's design. (Surely, being
*drawing* code it only needs read-only access to the data model. Or,
if it has drawing-related status to update in the data model, it
shouldn't be making structural alterations to the data model whose
failure could leave the model in an un-savable state.)
In this case, the location of the drawing is irrelevant. Its design
is dangerous to the data model no matter where it's implemented.
-- If a failure in the drawing code doesn't hurt the data model, but
leads to an unending cascade of exceptions from the inconsistent
drawing state, then the problem is more about suppressing exceptions
so that the document can be saved before the application crashes.
I assumed that Graham meant that if his user is creating stuff, then
during a draw the graphics get hosed to the point where the user can't
save, he will lose the data that he as created in that session.
When I worked in graphics, this type of problem was all too common in
Illustrator 5.0 I can assure you.
_______________________________________________
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