On Mon, Aug 03, 2009 at 02:34:37PM -0700, Danek Duvall wrote: > On Mon, Aug 03, 2009 at 02:29:34PM -0700, [email protected] wrote: > > > The only time that we'll print this message is right before we fail the > > assert. This is just extra information coming along with the assert to > > help us debug. I would think that the message is most useful if it is in > > the same place as the stack trace from the assertion failure. > > So perhaps the right answer isn't a message and an assert, but an exception > raised that can properly be handled by a higher layer.
The approach that you're suggesting does make it easier to figure out what's gone wrong, since it's possible to encode additional information about the failure in the exception. This also means that higher layers can perform their own output formatting. Is there any downside to this approach that I'm not seeing. The obvious concern was that other layers can catch and suppress the exception. However, with Python they could easily do the same thing with the AssertionError. In this case, the stack trace doesn't do us a lot of good anyway, so having a nicer message is probably better. I've seen cases in the GUI where they catch an exception that would have terminated the CLI, print a message, and continue. I would hate to get into a situation where we're printing random error messages and just carrying on. I suppose the real question is should this continue to be a failure that terminates the application. There's no real way to recover from the problem, and the assertion is there to make sure our code is correct. We shouldn't be hitting this in production code. In fact, there's some precedent for disabling assertions in production code. Should we be looking at our own class of assertion-like exceptions that we can enable/disable for production versus DEBUG? -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
