Bad Practice To Run Code In Constructor Thats Likely To Fail?

my question is rather a design question. In Python, if code in your 'constructor' fails, the object ends up not being defined. Thus: someInstance = MyClass('test123') #lets say tha

Solution 1:

There is a difference between a constructor in C++ and an __init__ method in Python. In C++, the task of a constructor is to construct an object. If it fails, no destructor is called. Therefore if any resources were acquired before an exception was thrown, the cleanup should be done before exiting the constructor. Thus, some prefer two-phase construction with most of the construction done outside the constructor (ugh).

Python has a much cleaner two-phase construction (construct, then initialize). However, many people confuse an __init__ method (initializer) with a constructor. The actual constructor in Python is called __new__. Unlike in C++, it does not take an instance, but returns one. The task of __init__ is to initialize the created instance. If an exception is raised in __init__, the destructor __del__ (if any) will be called as expected, because the object was already created (even though it was not properly initialized) by the time __init__ was called.

Answering your question:

In Python, if code in your "constructor" fails, the object ends up not being defined.

That's not precisely true. If __init__ raises an exception, the object is created but not initialized properly (e.g., some attributes are not assigned). But at the time that it's raised, you probably don't have any references to this object, so the fact that the attributes are not assigned doesn't matter. Only the destructor (if any) needs to check whether the attributes actually exist.

Whats a proper way of doing this?

In Python, initialize objects in __init__ and don't worry about exceptions. In C++, use RAII.

---

Update [about resource management]:

In garbage collected languages, if you are dealing with resources, especially limited ones such as database connections, it's better not to release them in the destructor. This is because objects are destroyed in a non-deterministic way, and if you happen to have a loop of references (which is not always easy to tell), and at least one of the objects in the loop has a destructor defined, they will never be destroyed. Garbage collected languages have other means of dealing with resources. In Python, it's a with statement.

Solution 2:

It is not bad practice per se.

But I think you may be after a something different here. In your example the doSomething() method will not be called when the MyClass constructor fails. Try the following code:

classMyClass:
def__init__(self, s):
    print s
    raise Exception("Exception")

defdoSomething(self):
    print"doSomething"try:
    someInstance = MyClass("test123")
    someInstance.doSomething()
except:
    print"except"

It should print:

test123
except

For your software design you could ask the following questions:

• What should the scope of the someInstance variable be? Who are its users? What are their requirements?

• Where and how should the error be handled for the case that one of your 10 values is not available?

• Should all 10 values be cached at construction time or cached one-by-one when they are needed the first time?

• Can the I/O code be refactored into a helper method, so that doing something similiar 10 times does not result in code repetition?

• ...

Solution 3:

I'm not a Python developer, but in general, it's best to avoid complex/error-prone operations in your constructor. One way around this would be to put a "LoadFromFile" or "Init" method in your class to populate the object from an external source. This load/init method must then be called separately after constructing the object.

Solution 4:

One common pattern is two-phase construction, also suggested by Andy White.

First phase: Regular constructor.

Second phase: Operations that can fail.

Integration of the two: Add a factory method to do both phases and make the constructor protected/private to prevent instantation outside the factory method.

Oh, and I'm neither a Python developer.

Solution 5:

If the code to initialise the various values is really extensive enough that copying it is undesirable (which it sounds like it is in your case) I would personally opt for putting the required initialisation into a private method, adding a flag to indicate whether the initialisation has taken place, and making all accessors call the initialisation method if it has not initialised yet.

In threaded scenarios you may have to add extra protection in case initialisation is only allowed to occur once for valid semantics (which may or may not be the case since you are dealing with a file).