gnustep-dev
[Top][All Lists]
Advanced

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

Re: libgnustep-base split proposal


From: Richard Frith-Macdonald
Subject: Re: libgnustep-base split proposal
Date: Mon, 27 Feb 2006 18:31:11 +0000


On 25 Feb 2006, at 04:37, Sheldon Gill wrote:

Richard Frith-Macdonald wrote:
On 23 Feb 2006, at 01:04, Gregory John Casamento wrote:

Actually ... I'm getting the impression that the best thing to do might just be not warn about missing external resources if the library is installed in a path other than System/Library/Libraries

Might I suggest:

library messages (base & gui) are assigned a level:

  Debug
  Technical
  Informational
  Warning
  Error
  Critical

and output is according to chosen level.

If the library is looking for a resource and can't find it
  If the problem means execution can't continue
    report as Error
  If the problem is likely to cause execution failure
    report as Warning
  Otherwise
    report as Technical

{Exact details, of course, to be agreed...}

Well, I think we already do that ....

A real error which means that execution can't continue ... should raise an exception and get logged that way. A severe warning (one notch down from fatal) should get logged with a simple NSLog() ... it shoulod always be seen. We have NSWarnLog() and friends for information/warning level of logging ... things we expect people normally want to see, but which can be turned off with a runtime option. We have NSDebugLog() and friends for technical/debug level of logging ... normally off, but we can turn them on with a runtime option.

So, only four categories rather than six ... even so, I think NSWarnLog() is hardly ever used ... I think it's really, really hard to assign some messages to particular categories ... for anything which is not a fatal error and is not clearly for debugging purposes, it's horribly different to classify, because what is appropriate usually depends on the audiance/user and what they are trying to do with the library.

However, an audit would be good ... I suspect a number of NSLog() calls should be NSWarnLog() or even NSDebugLog()

What I was referring to in an earlier email is the idea that in some circumstances (a normal install) missing resource files are a real oddity and mean that the program won't behave as expected ... which may well constitute a failure, but in other circumstances (deliberately installed without resources as a standalone library) you could assume that the lack of locatable resources was intentional, so any program using the library presumably expects the changed behavior and it is not a failure. Thinking more about it, this is probably not a good idea to infer from library location.





reply via email to

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