[EMAIL PROTECTED] wrote: >> True however it is caught in the exception after the failed attempt to >> do a lg.beList() and processing continues without error. > > You're right, the code will catch a NameError. The exception handling > you've chosen is a bit of a dragnet. If possible, I'd encourage you to > catch the exceptions that you actually expect to see. At least that > way, people reading the code have some idea about what might possibly go > wrong. > >> Each function call into BootEnv returns right away when libbe isn't >> imported. I chose this style instead of checking before each call is >> made in client.py. Keeps client.py cleaner. > > It took me a minute to figure this out. The way this is implemented is > kindof sneaky. I had to notice that every function starts with a call
OK maybe sneaky, but the intent wasn't to be. > to get_env() and get_env() checks is_BEenv. It might just be easier to > check is_BEenv directly inside the methods. There are a couple of other > possible approaches too: Yeah I wasn't sure what the OO convention was, wrap a variable in a method or just access it directly. If it is most conventional to access the member directly I'll do that. > > 1. Create an abstract BootEnv class, define BootEnvZFS and BootEnvNull > classes. When we can import libbe, use the BootEnvZFS class, otherwise > use the BootEnvNull class. Presumably, the null class has methods that > don't actually do any work. > > You could also just make the parent class have null methods, and then > have BootEnvZFS do work. There are a few different ways you could go > with this general idea. Stephen/Danek may want to say more about this, > too. > > 2. Override the __new__() of BootEnv to not create an object when libbe > cannot be imported. Of course, this means that you'll have to check > that your constructor returned an object. This, in turn, will push some > of the checking into client.py. Approach 1 may be easier. > Each of these are great ideas but wouldn't the first one create duplicate code? I'd like to try to avoid pushing code into client.py as you mentioned in #2. Would you be ok with me commenting the original way better so it doesn't appear so sneaky and accessing the members directly instead of wrapping them in methods? I appreciate your comments and insight. Thanks Tim > -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
