> >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. :-) _______________________________________________ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
