On Apr 5, 2012, at 5:59 AM, Ariel Feinerman wrote:
> the next provocative question is whether can we release self in init before
> raise an exception? I think it has own reason.
Yes, you can release self* in an init method before returning nil or raising an
exception.
Although if raising an e
Thank for your all and especially Jens answers
the next provocative question is whether can we release self in init before
raise an exception? I think it has own reason.
On Thu, Apr 5, 2012 at 12:05 PM, Andreas Grosam wrote:
>
> On Apr 4, 2012, at 7:33 PM, Corbin Dunn wrote:
>
> >
> > On Apr 4,
On Wed, Apr 4, 2012 at 9:38 PM, Dave wrote:
> Hi,
>
> If it's a real error, this is what I do:
>
> - (id) initWithURL: (NSURL *) url
> {
> self = [super init];
> if (self == nil)
>return nil;
>
> if (url == nil)
>{
>[self release];
>return nil;
>}
>
> retur
On Apr 4, 2012, at 7:33 PM, Corbin Dunn wrote:
>
> On Apr 4, 2012, at 9:29 AM, Andreas Grosam wrote:
>
>> The problem on Mac OS X in Cocoa Apps is, that there is no alert. The
>> application also does not stop, or terminate gracefully. The default
>> behavior of the event loop is to log an e
On Apr 4, 2012, at 11:48 AM, Klaus Backert wrote:
> Just to be sure what you mean: What is a real error? Simply an error which is
> not a programmer's (or programming?) error?
A runtime error, one that could occur in a valid program. What this means
exactly is up to the designer of the API.
F
Hi,
On 4 Apr 2012, at 19:39, Dave wrote:
Hi,
If it's a real error
...
If it's a programming error
...
Just to be sure what you mean: What is a real error? Simply an error
which is not a programmer's (or programming?) error?
Regards
Klaus
___
On Apr 4, 2012, at 10:33 AM, Corbin Dunn wrote:
> "AppKit now has the ability to report uncaught exceptions. It is controlled
> by a user default: NSApplicationShowExceptions (YES/NO). The default shipping
> value is NO. In general, it is recommend that developers set it to YES during
> develo
Hi,
If it's a real error, this is what I do:
- (id) initWithURL: (NSURL *) url
{
self = [super init];
if (self == nil)
return nil;
if (url == nil)
{
[self release];
return nil;
}
return self;
}
or in this case, you could just do this:
- (id) initWithUR
On Apr 4, 2012, at 9:29 AM, Andreas Grosam wrote:
> The problem on Mac OS X in Cocoa Apps is, that there is no alert. The
> application also does not stop, or terminate gracefully. The default behavior
> of the event loop is to log an error message, and then **continue**.
No, there is an aler
On Apr 4, 2012, at 9:55 AM, Jens Alfke wrote:
>
> On Apr 4, 2012, at 9:29 AM, Andreas Grosam wrote:
>
>> The problem on Mac OS X in Cocoa Apps is, that there is no alert. The
>> application also does not stop, or terminate gracefully. The default
>> behavior of the event loop is to log an er
On Apr 4, 2012, at 9:29 AM, Andreas Grosam wrote:
> The problem on Mac OS X in Cocoa Apps is, that there is no alert. The
> application also does not stop, or terminate gracefully. The default behavior
> of the event loop is to log an error message, and then **continue**.
Not anymore. In Lion
On Apr 4, 2012, at 5:57 PM, Jens Alfke wrote:
>
> On Apr 4, 2012, at 8:37 AM, Andreas Grosam wrote:
>
>> In a "debug" version, use NSAssert and friends (ensure Preprocessor macro
>> "NS_BLOCK_ASSERTIONS" is not defined). Use Unit tests in order to detect
>> *any* possible logic error. In a "r
The general rule is:
1. If it is considered a programming error, raise an exception (or assert -- it
is the same)
2. If it is normal code flow, then don't log or do anything strange.
However, in general, it is troublesome to have init's return nil.
corbin
On Apr 4, 2012, at 4:38 AM, Ariel Fein
Le 4 avr. 2012 à 17:57, Jens Alfke a écrit :
>
> On Apr 4, 2012, at 8:37 AM, Andreas Grosam wrote:
>
>> In a "debug" version, use NSAssert and friends (ensure Preprocessor macro
>> "NS_BLOCK_ASSERTIONS" is not defined). Use Unit tests in order to detect
>> *any* possible logic error. In a "re
On Apr 4, 2012, at 8:37 AM, Andreas Grosam wrote:
> In a "debug" version, use NSAssert and friends (ensure Preprocessor macro
> "NS_BLOCK_ASSERTIONS" is not defined). Use Unit tests in order to detect
> *any* possible logic error. In a "release" version where NSAsserts and
> friends may become
On Apr 4, 2012, at 4:38 AM, Ariel Feinerman wrote:
> I think the question was asked and answered but I cannot see a clearance
> what is the right way to write init in the cases the arguments are nil or
> wrong?
> Returning a nil or raising an exception?
If the argument values are literally wrong
On Apr 4, 2012, at 1:38 PM, Ariel Feinerman wrote:
> Hi,
>
> I think the question was asked and answered but I cannot see a clearance
> what is the right way to write init in the cases the arguments are nil or
> wrong?
> Returning a nil or raising an exception?
Well first, this is my personal o
17 matches
Mail list logo
