Chicago C/C++ Users Group Message Board › New mini-articles

New mini-articles

Conrad W.
CWeisert
Chicago, IL
Post #: 95
Two new items on my IDI website should interest members of our group:

http://www.idinews.co...­

http://www.idinews.co...­

As always, I welcome comments and constructive suggestions for improvement or follow-up.
Nevin ".
nliber
Libertyville, IL
Post #: 75
In Constructor Dialog, you say:

Illegal input may raise an exception or leave the object in anincomplete state.

Merits of this particular constructor aside, why shouldn't an exception be thrown in this case? That is usually what you want to do a constructor when the class invariants can't be met.
Conrad W.
CWeisert
Chicago, IL
Post #: 97

Merits of this particular constructor aside, why shouldn't an exception be thrown in this case? That is usually what you want to do a constructor when the class invariants can't be met.

It's very simple: If we shouldn't be doing something at all, then we needn't be debating how to do it.

At best exception handling imposes complexity upon code. Handling exceptions (a) that don't need to be raised or (b) that are raised in the wrong place opens the door to monster maintenance nightmares.
Nevin ".
nliber
Libertyville, IL
Post #: 77
It's very simple: If we shouldn't be doing something at all, then we needn't be debating how to do it.

It isn't that simple, especially since you made a comment about throwing exceptions from constructors in general. Given that exceptions were designed to solve that particular problem, that is a very curious statement to make.

At best exception handling imposes complexity upon code. Handling exceptions (a) that don't need to be raised or (b) that are raised in the wrong place opens the door to monster maintenance nightmares.

Does it really impose more complexity than error handling in general?

By that line of reasoning, most of the Standard Library would be unusable (since any constructors not declared noexcept, throw() or documented as throws nothing are allowed to throw).

My experience is the opposite of that. Objects that cannot throw exceptions in constructors lead to the so-called "2-phase construction" (calling an Init() method immediately after construction) to report errors, which leads to weakened invariants, more complicated non-private methods (they all have to check that the object is useable and somehow report an error) and a more fragile code base. Throwing from a constructor guarantees that you cannot leave the object in an incomplete state.

I don't advocate exceptions for all error handling. Asserts should be used for detecting programming bugs. Error codes are okay when you have to handle the error locally (i.e., not involving stack unwinding). But I don't see a better alternative than throwing exceptions from constructors for both reporting errors and not leaving an object in an incomplete state.

Given reasonable coding guidelines (cleanup happens in destructors, not catch blocks, never throw from a destructor, deleter or other cleanup code, derive all exceptions from common base classes such as std::exception, etc.), could you show us an example where exceptions lead to "monster maintenance nightmares" compared with alternate methods you employ to deal with errors when constructing objects?
Conrad W.
CWeisert
Chicago, IL
Post #: 99
It isn't that simple, especially since you made a comment about throwing exceptions from constructors in general. Given that exceptions were designed to solve that particular problem, that is a very curious statement to make.

I can't find "a comment about throwing exceptions from constructors" either in my article or in this meetup discussion. The article was about conducting on-line dialogs in constructors, or more generally doing input-output in constructors.

Does it really impose more complexity than error handling in general?

The discussion wasn't about comparing different ways of handling errors. It was about (a) handling quasi-errors that don't need to be handled at all or (b) trying to handle errors in a part of a program that knows nothing about them. The issue was about understanding modularity, not error handling.


Powered by mvnForum

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy