Re: NSSavePanel complains about .hidden

[Nicola Pero]

> >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 ?
> >
> Nope ... it's been there for years, and even when it was written it wasn't 
> new - it
> was just documenting the standard practice in NeXTstep and of the GNUstep
> community (almost all ex NeXTstep users at that point I think).

Ok - then it was standard practice for NeXTstep users ... I'm fine with
that - but it still doesn't mean it is an excellent technical solution.

 
> >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. :-(
> >
> There is a basic philosophical problem here ...
> In NeXTstep/GNUstep a log message to standard error is not considered 
> annoying and
> unwanted ... because normal users just don't see it, and developers find 
> it useful.

But if you are writing, say, a web server which is logging carefully to
stderr using a strict and predefined web-server specific format (possibly
customizable by the user in configuration files), then a log message to
standard error from the library is annyoing and unwanted.

In the domain of unix command line tools the programmer might well need
total control of stderr ... it *must* be possible to control this stuff,
at least to turn it off, or filter it, or postprocess it.

When your users are system administration / developers, then they see the
logs to stderr; stderr is part of the user interface for them.  To use
gnustep-base in that domain, it should be possible to have more control of
stderr.

NSLog() can never be turned off by the programmer, so if gnustep-base uses
hardcoded NSLog() to just write out arbitrary messages at his will, and if
you use gnustep-base to write your code, it's effectively impossible for
you to control what is written to stderr.

Which I find very limiting in a traditional command line environment.
 

> >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.
> >
> It's better than any other library, because it's reporting more potentially 
> useful information.

... I wouldn't go as far as saying it's better ... :-)

Maybe it's better in a certain domain where you don't need fine control on
stderr.  But it's definitely worse in a general sense for traditional
command line tools - with a traditional library such as libc you have
total control of the stderr output of your tool; by using gnustep-base you
don't.

gnustep-base is built on top of libc, so all information you have, you get
it from libc - and you get it because libc reports it to you via a public
API, and does not just return a vague error (nil) to the software, while
writing the actual reason in a format readable only by a English-speaking
human sysadmin to stderr.


> >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 ?
> >
> MacOS-X has moved towards more use of exceptions ... but they are careful to
> document cases where they raise an exception in an init method ... because the
> norm is not to.

They might be careful in documenting exceptions in -init methods, which is
good; and still they should be equally careful in documenting when an
-init method fails and returns nil ... because if they don't, nobody would
check for it (nobody checks the result of each -init call), so I'd say the
general norm is rather that -init methods never fail. :-)