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