On 16 Jan 2009, at 8:33 pm, kyle.slu...@gmail.com 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 (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
