On Mon, Aug 03, 2009 at 02:51:41PM -0700, [email protected] wrote: > > 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.
I'm not aware of any. Though it might be a little saner, instead, to simply return a list of these errors, rather than dealing with an exception. It depends on what the rest of the stack looks like at that point in time, I guess. > 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. True; I'd forgotten that. But an assert still doesn't carry as rich data as a custom exception would. > 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. If there's really no way this can happen in real life, then it makes sense the way it is. > Should we be looking at our own class of assertion-like exceptions that > we can enable/disable for production versus DEBUG? Turning on optimization will disable asserts (in fact, I think it's just about the only thing optimization currently does), so in principle we could do it if we wanted to. Danek _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
