Original Post
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!