> On Jul 1, 2015, at 18:05 , Quincey Morris > <quinceymor...@rivergatesoftware.com> wrote: > > On Jul 1, 2015, at 17:50 , Rick Mann <rm...@latencyzero.com> wrote: >> >> I didn't think it was possible to not return. Maybe an assert() is better in >> this situation, because I think it always indicates a programming mistake. > > Indeed it is possible. There are three possible functions: > > fatalError (“message”) > preconditionFailure (“message”) > precondition (booleanCondition, “message”) > > I’m not sure what the difference is between the first two, but I’ve noticed > that ‘fatalError’ crashes with an illegal instruction — deliberately, I > assume. > > ‘assert’ isn’t a good choice, because it doesn’t do anything in a Release > configuration build. That’s where it’s actually more important for it to > crash.
Ah, good to know about those others, thanks. I think assert is still a good choice here, in that (I think) the problem will always come up if this class is used in the wrong place, and will never come up if used in the right place (if it does, way more has gone wrong in the execution). It avoids the runtime check (which might not be moot in drawing code) in release code. -- Rick Mann rm...@latencyzero.com _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
