Re: NSSavePanel complains about .hidden

[Richard Frith-Macdonald]

Nicola Pero wrote:

> > > > Richard latest changes to NSData caused that the NSSavePanel now 
> > > > complains, if it cannot find a .hidden file in a directory:
> > > >
> > > > 2002-10-05 13:21:29.687 Ink[1323] File NSData.m: 219. In 
> > > > readContentsOfFile Open (/.hidden) attempt failed - No such file or 
> > > > directory
> > > >        
> > > I'm not sure if it is a good policy that the base library jumps to talk
> > > directly to the user (/stderr) ... because it's a very inflexible /
> > > uncustomizable behaviour - the library should instead allow the program to
> > > perform/provide its own checks / error routines, which might depend a lot
> > > on the situation - a NSLog might be totally inappropriate.
> > >
> > >      
> > When run in a graphical environment, a User wouldn't even typically see 
> > these message, since they would go to the console. NSLog messages are 
> > more for developers and bug tracking.
> >    
>
> I'm not sure ... I just think they should be NSDebugLogs and not
> NSWarnLogs, since they are not warning about possible programming errors
> in the user code, but rather providing information which might be
> potentially useful for bug tracking.
>
>
>  
>
> > > NSString +stringWithContentsOfFile should return nil if the file can't be
> > > opened ... it is up to the caller to decide what to do in that case, if
> > > this is perfectly acceptable or it is a major error, if it needs to be
> > > logged to stdout / stderr / a file / displayed in an alert panel /
> > > whatever, or if it can be ignored (as in the case of NSSavePanel).
> > >      
> > Well, it would be nice if the reason for the error could be stored 
> > somewhere (like Unix's errno/errstring).
> >    
>
> I don't understand why you are assuming that +stringWithContentsOfFile
> returning nil is an error.  The caller will assess that.  In the case of
> NSSavePanel, for example, it's a perfectly valid condition.

<pedantic>Technically a nil return here indicates a failure ... an 
error.  I'ts up to the caller to decide how to deal with that, not to 
decide whether it's a failure or not.</pedantic>

> This is why the warning should be a NSDebugLog - off by default (as it is
> an undocumented and possibly unwanted warning about a 'maybe error', not
> an actual official error), and should only be turned on if you require it
> by using the appropriate --GNU-Debug stuff.
>  

The warnings are 'warn' logs ... you can control whether they are 
compiled in to the
library or not.

The purpose of a warn log is to highlight things that the progrmmer has 
done which
we think are probably wrong (not cases where we are 100% sure ... in 
those cases we
would have an NSLog() or raise an NSException) and provide them with 
guidance to
improve their code, as well as providing more technically savvy users 
with some
diagnostic aids.

The fact that both Adam and I independently chose the same mode of 
logging here
indicates to me that we probably both think that attempting to create an 
object from
a file in order to determine if the file exists or is readable (when 
there is an API for
doing exactly those tests) is bad programming practice, and that 
therefore in most
cases where an attempt to read from a file fails, there has been a 
programming
error of some sort, and we ought to let the programmer know so they can 
improve/fix
their code.

Obviously deciding on these logging modes is a judgment call, there is 
no clear objective
criterion.  I think ten years ago I'd have argued that attempting to 
read a file is a convenient
shortcut where you know you want the info in it if it exists, but don't 
care if it doesn't.
Nowadays experience tells me that the shortcut encourages laziness, and 
you should
be checking first, and going to the effort of writing code to handle 
problems.
So I think the current balance of logging is about right ... though as 
usual I'm happy
with majority verdicts on  these subjective issues.