bug-gnustep
[Top][All Lists]
Advanced

[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: Mon, 07 Oct 2002 11:26:08 +0100
User-agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.0.0) Gecko/20020622 Debian/1.0.0-0.woody.1

Nicola Pero wrote:

<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 ?
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).

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. :-(

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.

The other misconception in the paragraph is the idea that NSLog() is reporting to the caller (software)... of course it's reporting to the developer/administrator (human).

I think the idea is that init methods should rarely fail becaause the program code should have validated their argument first ... it's just a programmming convention.

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.
You don't have to read it.

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.





reply via email to

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