C++, "canceling a construction"

Hi /prog/

My is simple, but perhaps not so frequent.

How should I stop a construction of an object (c++)?

Basically I have a class with some data members which must fulfill some requirements. Say we initialize these data members upon construction, if the supplied values were erroneous then I guess I want to stop construction and throw an error. Is this the right idea? How do I "cancel the construction"?

Help much appreciated :)

>>44
So what you're saying is that when you're shipping code, the best way to find the cause of a bug is to just call abort()
No genius, you never call abort() directly; you assert() to verify the arguments. abort() is caught by debuggers giving you a stack trace, and for QA testers it's extremely easy to write your own replacement to throw up a dialog or output debug info and stop execution. QA just sends uploads the log file or a screenshot of the dialog in their bug report (on some platforms you have no log support; e.g. on iPhone we use a popup dialog). I wrote this facility at work, it's not fucking difficult.

And the abort()s can then disappear in production, but they don't have to. Honestly now, if you encounter an error in production that was *not once* reproduced in QA, how is throwing an exception at all better than giving the end-user a dialog with debug info? Seems far worse to me; it's not possible to write code able to gracefully handle 'any exception anywhere', so most likely your program will crash horribly.

Throwing an exception is a *horrible* idea, because if it's caught then QA can't give you reliable debug information (reflection on stack traces doesn't exist in sepples remember), and if it isn't caught then the app just crashes.

And I just want to clarify before some troll trolls this: this is *NOT!!!* how you validate user input. You do that separately, at the point the input is received, without exceptions or any other bullshit.

>>44
I just want to doubly highlight the stupidity of this:

the best way to find the cause of a bug is to just call abort()? May I ask how, the fuck, do you expect to gather debugging information after that?
You can't gather debug information *AT ALL* from exceptions. They don't even have a stack trace. Sepples exceptions are *entirely useless* for debugging.

On the other hand, you can replace abort() to take __LINE__ and __FILE__, and you'll know exactly what's wrong locally (and there are platform-specific tools to run through the linked-list on the stack; if you include a debug symbol table for your QA builds you can easily get a full stack trace out of it). This also works in and across C code, not just sepples bullshit.

And most importantly, debuggers halt on SIGABRT, so you can easily investigate the call stack interactively (as opposed to your app dying due to an uncaught (or worse, caught with ...) exception, and setting up your debugger to catch specific exception types, and trying to replicate it and stepping through all the ones you aren't interested in...)

>>48
One last note, as is mentioned repeatedly in the FQA, this is not the state of affairs in sane languages; almost every other language with exception support has garbage collection, reflection, stack traces, etc. You know, things that make exceptions actually *possible to use*, let alone *good*.