Re: NSSavePanel complains about .hidden

[Nicola Pero]

> > <pedantic>An 'error', for the programmer using the base library, is when
> > the base library generates an exception.  Anything else is not an error.  
> > A nil return here indicates that the file doesn't exist, is not readable
> > or can't be read.  This is considered a valid result, otherwise the API
> > would have required an exception - with the name and reason of the error -
> > to be raised.</pedantic>
> > 
> 
> That's not true. init methods are not supposed to generate an exception, 
> they are supposed to log an error, release the object and return nil (at 
> least the way we currently specify it, see 
> http://www.gnustep.org/resources/documentation/coding-standards_5.html#SEC5 
> - if we want to change that, it's a different matter).

Ok - you're probably right about init and the <pedantic> discussion was
just pedantic :-) - but I didn't know about that section nor that raising
exceptions in -init was forbidden, is this 'coding practice' a new
addition ?

I don't like it.  The whole section I mean.

Always having -init return nil to the caller (with no info of what went
wrong), and using NSLog to report the error to stderr is really
inflexible, a very poor way of managing error situations.  The software
has no way of knowing what the error was, and we are printing a
potentially annoying and unwanted string to stderr. :-(

I'd say it's worse than what any other library in the system is doing.  
Even something as primitive as libc does not clutter stderr with errors,
and is supposed to report them ordinately to the caller instead, for the
caller to manage them.

I don't see why the policy should be to always return 'nil' to the caller
in 'init' if something goes wrong - the documentation of other OpenStep
systems say that it's perfectly correct to raise an exception inside
-init, and that it depends on the class ... why are we forbidding to
ourselves the use of the richer NSException API ?