On Sunday 19 Jul 2015 14:59 CEST, Chris Angelico wrote: > Reordering/interleaving your post to respond to different parts > together. > > On Sun, Jul 19, 2015 at 8:35 PM, Cecil Westerhof <ce...@decebal.nl> wrote: >> I am using libturpial to post things on Twitter. But sometimes I >> get a ServiceOverCapacity exception. So I wrote the following code. >> >> ====================================================================== >> class InitAlreadyDoneError(Exception): pass > >> Is this the correct way to work user defined exceptions, or should >> I also define a default message? > > I'd start by looking through the exception hierarchy for something > appropriate to subclass. In this case, you're basically saying "run > init() exactly once, and if you run it a second time, I'll throw > back an error", which probably doesn't have any logical match, so > directly subclassing Exception would be correct. But you might > decide that subclassing ValueError or RuntimeError is more > appropriate.
Subclassing ValueError or RuntimeError looks wrong to me. >> ##### Functions >> def init(max_tries = 5, wait_time = 60): >> global _core >> >> if _core != None: >> raise InitAlreadyDoneError > > This is where I'd add a message, if you want one. But it looks to me > as if there's never going to be any other place that raises this, so > the message would be redundant. InitAlreadyDoneError implies "you > called init() after someone else called init()". I thought so, but just wanted to be sure. ;-) > (Side point: It might be a neat courtesy to let people call init > again, or maybe a try_init() that won't error out if already > initialized.) I changed it to: ======================================================================== def init(max_tries = 5, wait_time = 60, reinit_allowed = False): global _core if (_core != None) and not reinit_allowed: raise InitAlreadyDoneError ======================================================================== >> I use this in the following way: >> import twitterDecebal >> twitterDecebal.init() >> >> Because you can not give parameters with an import as far as I can >> see. Is this a good way to do this, or is there a better way? > > Parameterized imports aren't possible, correct. What I'd look at > here is a more explicit instantiation. Something like: > > import twitterDecebal > twitter = twitterDecebal.twitterDecebal(5, 60) I worked with default values, because I thought that would be a good idea. I should remove the default values? > Especially since it's something that does a ton of network > operations and all sorts of sleeps and timeouts, I would strongly > recommend NOT doing this on import, even if you could. If you don't > absolutely _need_ it to be global, it'd be cleanest to make it a > class that you construct. In principal I only mend that before you use the twitter functions you need to do the init. (And because of the ton of functions I wanted a reinit to be an error.) In my case it is exactly below the import. Because I use it in a script and except one situation _core is always used. So I thought it to be more clear. -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof -- https://mail.python.org/mailman/listinfo/python-list