[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSSavePanel complains about .hidden

From: Richard Frith-Macdonald
Subject: Re: NSSavePanel complains about .hidden
Date: Wed, 9 Oct 2002 11:06:49 +0100

On Tuesday, October 8, 2002, at 01:31  pm, Nicola Pero wrote:

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.

No ... but I think it probably is quite a good solution (IIRC I argued against it at the time and was converted by Adam and others), and it's important to
have a standard convention.

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.

So turn it off (or redirect it to syslog) in those circumstances.
Of course, in those cases it's really the webserver which is misusing stderr -
so I'd fix that if it was simple to do so.

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.

Agreed ... and the programmer has the capability to do that of course.

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

What more control?

NSLog() can never be turned off by the programmer,

That's not true.

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 think most of the 'issue' here is actually that you don't know what the logging capabilities of GNUstep are. This is probably in large part due to
the lack of documentation (you would have needed to read the source).

I've updated the code to make warning logs controllable at runtime rather than just compile time (as I mentioned yesterday) ... but more importantly, I've converted the comments in the source code to be in autogsdoc format, as well as adding quite a few comments, so the basic NSLog capabilities should now be
reasonably well documented.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]