Hi Stephan, > However, > contrary to how you read it below, I never intended to suggest that > aborting on an assertion was not appropriate in a product build. It is > my firm belief that a program that aborts upon assertions is arguably > more robust than one that carries on (however paradoxical that may > superficially sound). > ... > If common understanding indeed is that OSL/DBG asserts flag situations > where "[s]omething didn't go the way it was intended/expected" *in the > sense that it is "a bug,"* then, honestly, for a product like OOo, I > see absolutely no reason not to abort in such a case.
I intentionally did not want to discuss this in this thread here, we both know that we have absolutely contrary opinions on this, and it doesn't really help us solving the current question. So, please let's leave out that question whether an end user program such as ours is allowed to crash, if it could prevent this - we won't come to an agreement on this here and now, as we never did whenever we discussed that :) > The thing I would agree on is that there are most probably uses of > OSL/DBG asserts in the OOo code base that do not flag bugs in the > software itself, but rather flag inappropriate or otherwise interesting > events, like unexpected user input or a full disk when the user tries to > save a document. These inappropriate asserts have to be changed to > things like OSL_TRACE. Which again (what a revenant ...) touches the question of available diagnostics ... Well, I know for sure that I wrote thousands of assertions in the last 10 years which *do* indicate bugs, and changing them to something like OSL_TRACE is a no-go for me (since this would downgrade them to purely informational status). So, at the moment we have assertions which a) should be traces, really b) indicate real bugs, but are recoverable (yes!) and c) indicate bugs, and are unrecoverable. All of those are currently mapped to a message box, which is the problem. I suppose a main point where we disagree is how we solve this, by mapping each and every occurrence to what it really should be. > My hope would be that > this---trivial---adjustment would happen over time, whenever somebody > stumbles over such an inappropriate assert firing. Yes. I also think that we should let this evolve a little bit. Where we disagree is that I don't think aborting is an appropriate measure. > (And, enabling > aborting assertions in product builds should seriously only be > considered when it is known that there are no obviously inappropriate > assertions in the code. One more reason why for now I am fine with > keeping assertions disabled in product builds.) Yes. > I assume that software developers strive to produce quality software, > that they are intrinsically motivated, and that they are interested in > using whatever adequate tools are available to help them. Like tests, I > consider assertions useful tools here. However, as I outlined in the > issue, the current state of assertions in OOo is such that they are not > useful, so developers do not consider them an adequate tool, so keep > away. My hope is that once assertions in OOo *are* a useful tool (i.e., > once that backdrop of existing assertion noise is weeded out, and each > assertion a developer sees fire with high likelihood points to an error > in the code she wrote five minutes ago) people will actually use them. We're on the same track here. One nit to pick: Changing, hmm, medium level code such as svtools will always bear the risk that you cannot check *all* existing clients, and all existing call combinations / code paths. That's simply impossible with a lot of classes there. So, stumbling over an assertion not necessarily means you introduced the bug 5 minutes ago. However, it still means somebody should be *urged* to fix it. > Of course, what I want to reach with that issue is not reached (and the > issue not fixed) by simply letting assertions abort. Okay, misunderstood this then. > We need a plan how > to reach the desired zero assertion state. I consciously left it open > for now how that plan should look like---I simply do not have the time > right now to think about it in the necessary depth. Well, I read the issue as "the plan is to let assertions abort", which I think, as said, won't work. > However, what is my firm belief, is that aborting assertions are the > only viable way to ultimately reach---and then keep---the zero assertion > state. I consider this technical approach a beautiful, highly effective > measure. I might change my opinion on this once we have an effectively assertion-free product. At the moment, we don't have, and we didn't have back in times where assertions were considered P2 (like: fix immediately) bugs. > Much more effective than any social approach, which would be > prone to be circumvented, and which we have seen fail for too long by > now. (There are analogies to our earlier warning-free code project. If > compilers would not technically enforce warning-freedom, we would by now > have lost it in large parts of the code again.) In principle, I agree. However, making assertions abort still can be circumvented: don't use non-product builds. This is where your analogy doesn't work. And as long as you still have this social component - allow to circumvent assertions -, the technical approach alone won't work, but punish the wrong people doing the right things, instead of punishing the right people doing the wrong things. > I agree with your points. However, to repeat, I see no easier, more > effective way to come to and inhabit that wonderful land you describe in > your points than by letting assertions abort. And, to repeat, I doubt that letting assertions abort will allow us to reach that land. > Frank, assuming we have somehow reached that land (following the plan we > still have to work on), would you then still have objections against > aborting assertions? See above. Probably not. (With the restriction that we would still have to solve the problem of our different definition of "assertions", and whether bailing out gracefully instead of crashing in a product build is desirable/possible/reasonable/advised. However, I really think this is the second discussion to have, at a later time.) Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
