On Mon, Oct 26, 2009 at 12:57 PM, Dick Bridges
wrote:
> IIUC,
> http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/Exceptions/Exceptions.html
> is available to everyone and is not under NDA. It's the "Introduction to
> Exception Programming Topics for Cocoa". As noted on this
> -Original Message-
> From: Alastair Houghton [mailto:alast...@alastairs-place.net]
> Sent: Monday, October 26, 2009 4:02 AM
> To: Dick Bridges
> Cc: Squ Aire; cocoa-dev@lists.apple.com
> Subject: Re: Professional Error Handling
>
> On 25 Oct 2009, at 22:44, Dick B
On Oct 25, 2009, at 3:44 PM, Dick Bridges wrote:
FWIW, there are some people (myself included) that consider "error
numbers" to be something of an anti-pattern when exception handling
is available. Because of [IMHO] improvements in gcc, Objective-C now
supports exception handling and it mi
On 25 Oct 2009, at 22:44, Dick Bridges wrote:
FWIW, there are some people (myself included) that consider "error
numbers" to be something of an anti-pattern when exception handling
is available.
There are also some people (myself included) that consider that you
are wrong.
This has been
On Sun, Oct 25, 2009 at 3:44 PM, Dick Bridges wrote:
> N.B. Switching from error codes to exception handling can be somewhat
> disconcerting initially so it's probably not something you'd want to take on
> if you are under strong time pressures.
In Cocoa, we don't use exceptions to handle cases
a-dev@lists.apple.com
> Subject: RE: Professional Error Handling
>
> > On Oct 22, 2009, at 7:40:46 PM, Squ Aire wrote:
> > And then of course return NO or nil from the method. Is this how the
> professionals would do it?
FWIW, there are some people (myself included) that consider &
On Oct 23, 2009, at 7:03 AM, Squ Aire wrote:
I'm not much for the second suggestion of putting all the errors in
one big header file (thanks for the idea nonetheless!). I like the
idea of seperating it like you have, only that I'm not sure what
purpose it serves to make it available to all
Thanks, I like your idea. If I understood your correctly, the code in your
example is for the files ExpressionProcessor.h and ExpressionProcessor.m.
If that is the case, why not just put it all in the .m file? And do "static"
instead of "extern" on the error domain string. That way you have a l
On Oct 22, 2009, at 4:40 PM, Squ Aire wrote:
And then of course return NO or nil from the method. Is this how the
professionals would do it?
Basically, although I have a utility function that does most of the
work, so I don't have to dump ten lines of boilerplate into my code
every time
Regarding your second case specifically, I usually define an error
domain and error codes using an extern NSString* const plus an enum on
a per-class basis.
// This for the header
extern NSString *const ExpressionProcessorErrorDomain;
enum {
EPUnmatchedParenthesesError = 21,
EPRadix
As my code base grows I'm starting to think there something wrong with my
error handling code. The following is my current error handling method:
MODEL OBJECTS:
I do methods in my MODEL objects, that could result in an error, like any
normal person would, namely to have the famous "NSError *
11 matches
Mail list logo
