   Errors Fix, Ignore, or Fail?
  Well, now I come to you all, with a question on a matter of opinion, that being, I need to know what the general concensus is with regards to matters discussed below.  All opinions are welcomed!Anyways, as always, I shall start by outlining 'the deal'.  Basically, as I was reworking my logging system so that it doesn't allocate any memory off the heap (so that I can start it up before the memory manager), I found myself in a quandry, with regards to errors.  Typically, I would just, on finding an error like calling the write function of a log sink not opened, return a failure value, exiting the function immediately after some small cleanup, or some other insidious method of making sure that it was noticed (not exceptions though, that is clearly not an exception case).  Now, that's all well and good, until I got to thinking about why I should actually fail the whole function just because of something small like that?  This is the Fail method, referenced by the title.So then, I rewrote it so it simply ignores things like that, returning a success value if, as in the example, you try and write to a closed log.  This way, I don't have to check for errors all over the place, which allows me to trim down the public interfaces of some classes because they don't need to be checked as much by 'outsiders'.  However, it also occured to me that if I do things this way, I am encouraging the programmer to just be lazy, and not pay attention to all the error handling he should be doing.  This is because, when errors become trivial things that can simply be ignored, the programmer will feel no qualms about running headlong into error after error with little abandon, because there are no consequences.  (Note that this is the worst-case scenario, that is, me after a long day, coding when I should be sleeping [grin])  Also, this method means that, even should you want to, you won't really be able to tell if functions are acting up, writing to closed logs, etc, because there is no external indication that the write call didn't do anything, because the sink was closed.  This is alos, in my opinion, a bad thing, because I like having the possibility to track everything.  This is the Ignore method.Then, last but not least, there is the fix method, where, taking the example above, the write function, when called on a closed sink, will simply open up, and then write to itself.  This seems to be the worst method of the three, because oftentimes, the log sink's writing function will not have access to enough data to give the opening function the proper parameters, or something else, so I would end up putting in a lot of code twining together things that should be distant, etc.  The very opposite of what I am trying to do with my sub-system plan.  But a solution nonetheless, which I feel is worth putting out here, if simply for others to agree with me on my judgement of it.Now, this is assuming the error is not critical enough to warrant extreme methods or exceptions, the errors that would be handled are minor things that won't kill the program should they fire.  So I'm curious as to what sort of system you all (would?) use, out of those three, for this sort of case?  I haven't decided yet, but I'm trying to come to a decision soon, so I can put it in my standards, and then stick to it.  As noted above, any and all opinions are welcomed!Cheers!PS. If my logging system arouses interest, (yes, I know, surely that's just my ego speaking, but I'd like to think I came up with a good solution to my logging problems [smile]) then please do PM me and I'll explain it in most of it's gory detail!   
  By "log sink", I assume the output log file?My suggestion is this - if you're not using exceptions, and so are using return values, and so the error could be ignored. Make the error ignorable.In other words - have the "Open" function return false if it fails, and just make the "Write" function do-nothing if there is nothing to write to.This gives the following usage possibilities:1) The file is opened and written to as you would expect2.1) The file is never opened, the return value is not checked, and the logger does nothing.2.2) The file is never opened, the return value is checked and the user is asked: "can't open logger, do you wish to continue?". (Or something else could be done - trying a different filename, etc.)This is also good, because it means that all of the above possible outcomes are easy to implement by the "end-user" of your logging class. And it means that there are no "fall-over-and-die" states possible.On the subject of a "close" function - just make it act like a failure to open a file that is ignored - have the logger do nothing.My own logger handles opening and closing in the constructor/destructor. You can use these without using the heap (use the stack) - although if you must use static, then you're probably unable to use them.Whatever you chose to do - you should remember - it's just a logger - does it really matter if the obscure occasion occures that the output file can't be opened (or the file has been closed by the programmer)? It's only used for simplistic debugging anyway.   ;  Well, actually, LogSink is an 'extension', or mix-in class, which provides the (pure virtual) write interface, taking a logstream as an argument. This means that if you want any class to be loggable to, you simply inherit from the LogSink class, and provide the requisite functions (that are pure virtual in the base class).  The default log sink provided for the end user in my case just dumps it's inputs, but this way, you have all the possibilities open, you could log to an in-game console, to a socket, whatever, just provide the class and use the provided APIs to load it up.Anyway, thanks a lot for the opinion, it pretty much conincides with what I had concluded, and as such has served to make me that much more confident in my decision, which can't be a bad thing [grin]  Anyway, as always, the more the merrier, I always thought gamedev was an opinionated lot, don't prove me wrong now folks!   