Exception handling in class constructors

[MasteR]

I'm after some opinions on how best to handle exceptions in class constructors.

 

Mock example:

I have an application log class.

When an instance of this class is created the class constructor creates(opens) an output file ready to write to.

 

As above, opening a file could cause an exception for a number of reasons.

 

The issues are that class constructors have no return type so returning an error code indicating that something went wrong is not an option. Using "throw" to throw an exception or error code will crash the program unless the class instance was created inside a try/catch block.

 

Possible solutions: (none of which I'm 100% satisfied with)

* Create classes using the named constructor idiom.

* Pass an error code variable to all class constructors as a pointer/reference argument. This allows the class constructor to modify the error code in the event of an exception, being a pointer/reference the error code can then be analysed from outside of the class.

* Give all classes a public "Initialise" method that must be called after an instance is created and also before any other class method is used.

* Give all classes a public/private error code variable which the class constructor can modify in the event of an exception. This member variable can then be analysed from outside the class via a “Get” type method.

 

Which solution do people use/prefer, or does anyone have an alternate solution they'd be willing to elaborate on.

[Rick]

I don't mind an Open() method. It's how the .NET database stuff works and I'm fine with that.

[MasteR]

As a semi separate question from the above.

 

As a programmer, how annoyed would you be if you were forced to encapsulate a class within a try/catch block, because the class threw exceptions rather than returned error codes?

[Josh]

This is one reason I decided to use Create() functions in LE3.

[Rick]

I prefer exceptions over error codes these days.

[MasteR]

This is one reason I decided to use Create() functions in LE3.

 

The issue here is if a programmer does not call the Create()/Initialize()/Open()/etc. method but instead begins using the object as normal...well needless to say the results are undetermined.

In this instance is it better to check a "fail bit" inside all class methods before executing code or simply take it on faith that the programmer will do the right thing?

[Josh]

Which results in less code? There's your answer.

[L B]

Try/Catch over class initialization is a perfectly fine practice, at least, in C#/.NET (in which exceptions play a major role). I see no reason to create a separate method.

[Laurens]

I'm an advocate for throwing exceptions in constructors as well. After a constructor has been called, the object should be in a fully usable state and not in some unusable zombie state that requires more methods to be called for proper initialization.

 

A try-catch clause does not result in more code either. More like the same as an if-then-else.