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 :)

Read about exceptions.
http://en.wikipedia.org/wiki/Exceptions

NO EXCEPTIONS!

>>2
Thank you for your contributing post.

Anyway my idea of going about this is that the constructor checks for errors,throws an exception if anything is awkward, if not initializes the data members.

And the object is destroyed if an exception was thrown.

Is this a sound solution?

>>3
Yeah, that's pretty much it.  If the exception is thrown, the object is never created, so you don't need to explicitly destroy the object (ie. call the deconstructor).

Make the constructor private and use a static "create" member function that validates the constructor parameters and either returns a new object if they were OK or a NULL pointer if they weren't.

There's probably some faggy pattern name for this, but that's too ENTERPRISE TURKEY SOLUTIONS for me.

>>5
Unless he wants information about how/why the parameters are invalid, then using exceptions would be better.

>>5
In other words, use C, and fuck sepples. Sound advice, anon.

>>6
Exceptions are never better, NO EXCEPTIONS!

>>7,8
Cool NS_ENSURE_SUCCESS() / SVN_ERR() / APR_SUCCESS_CHECK() / if() < 0 return -1 every fucking call, bro.

>>9
cool exception safe code in seeples, bro

>>1
Yep, throw. It's the only way. http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.17

Actually what you should do, is take your laptop, lock yourself in your basement, and absorb the entire C++ FAQ Lite. Then you might start to get some basic understanding of sepples. Don't feel bad; it's not actually possible for anyone to be good at sepples.

it's not actually possible for anyone to be good at sepples.
This is why we learn to handle all our OOP needs (if any) in C.

>>11
Don't forget to read the unfaq too.

>>1
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?
No. You should abort(). Let whatever fucker is using your code know that you won't tolerate his bullshit.

You should never attempt to recover from 'stupid programmer' errors; the louder you make it complain, the quicker the bug will be fixed, and vice versa.

In general, if you need to signal constructor failure for a valid reason which the app might reasonably encounter in the real world and from which it can recover, you should throw. An example is if it needs to open a file that doesn't exist. But never litter your code with throw statements for stupid bullshit. Every throw statement in the app is a massive maintenance and audit headache.

it's like nobody actually understands OOP
It's hardly surprising when I've heard at least 50 different versions of what OOP means

>>15
How can I learn to "understand OOP" properly?

>>15
WTF? I have an object representing an on-disk data structure which has methods for reading and manipulating it. Why the fuck would this not open a file? Why the fuck would the constructor not fail if it can't access the data structure it's supposed to represent?

Is my solution not fucking complicated and enterprise enough? Is that it? Do I need an ObjectFileProtocol and a FileSecurityPolicy and a FileAccessorFactory? No. The constructor opens the file and the destructor closes it. The methods manipulate the data. Simple, RAII, encapsulated, exception safe. How is this not object oriented?

>>15
Also, how the fuck is opening a file in a constructor a 'heisenbug'? It's a very obvious and explicitly defined point of failure; if the file doesn't exist, this constructor will throw. You need to catch this somewhere and display an error to the user.

We used to say heisenbugs are the kind of bugs that disappear when you try to debug them. I don't think that word means what you think it means.

irc.freenode.net ##C

>>19-20
：，（

Each anon's death diminishes me,
For I am involved in EXPERT PROGRAMMING.
Therefore, send not to know
For whom the /prog/ trolls,
It trolls for thee.

>>15
protip: std::ifstream
>>19
>How is this not object oriented?
It's seeples, it can't be object oriented.

>>5

It's called [[NSObject alloc] init].

>>24
A far superior solution, but the OP stated he's bound by sepples.

CONSTRUCT MY ANUS

>>26
my troll-sense is tingling

Ding-a-ling-a-ling!

>>28
You can sense danger like a troll?

>>4
This might be considered splitting hairs, but the object is indeed "created" prior to invoking the constructor; as in, memory is set aside for the data members, they simply aren't set to anything meaningful prior to construction. I should point out that if you have allocated any memory in the constructor prior to the exception being thrown, you must make sure that that memory is reaped from inside the constructor.

>>29
Dong-a-long-a-long!

>>31
By the C++ standard, an object is not created until the "return" statement of the constructor is being executed.

>>33
I think you've misunderstood my post, though like I said this is kind of arguing semantics. Suppose you had a class containing two 4-byte integers, using 1 byte padding with no virtual table for simplicity, making the object size 8 bytes.

When you declare an instance of this object, 8 bytes will be set aside for this object on the current stack frame, prior to invoking the constructor. A pointer to the beginning of this block of 8 bytes is passed into the constructor as the 'this' parameter.

If an exception is thrown, this block of 8 bytes continues to exist until the stack is unwound in the epilog stub of the calling function.

I feel it's erroneous to state that an object isn't created if an exception is thrown, as this implies there are absolutely zero side-effects if this occurs, when, from the point of view of the generated machine code, this isn't the case.

>>34
Not >>33-chan here, but you can't just dismiss it as a semantic argument; the semantics are *extremely* important. In C++ lingo creation is synonymous with construction. The object is said to exist only when its constructor has successfully completed execution. If it does not successfully complete, the object never existed.

I feel it's erroneous to state that an object isn't created if an exception is thrown, as this implies there are absolutely zero side-effects if this occurs
It does not imply that at all. What sane rational person would expect no side effects from something that throws an exception??

Besides, it's extremely rare that you need to worry about the side effects, since allocated memory using new is automatically released (as are stack objects of course) which has effectively no side effects (certainly no performance issues comparable to propagating the resulting exception). You only need to worry about the side effects if you are writing an overloaded new operator, or using placement new on some manually allocated memory, or some other perversion of the allocation system.

I should point out that if you have allocated any memory in the constructor prior to the exception being thrown, you must make sure that that memory is reaped from inside the constructor.
Yes, this is unfortunately a common error. The resulting constructors are ass-ugly too if you try to do it with try/catch (it almost looks as bad as Java). The vast majority of these issues are solved with a simple smart pointer though; it only gets ugly if you are e.g. filling an array with allocated objects and one of them throws. Boost's pointer containers help.

This is honestly the biggest reason I am looking forward to sepplesox. With move semantics and perfect forwarding, there is now the universal unique_ptr for unique ownership. Finally a smart pointer with *zero* overhead of any kind which you can safely put in containers, return from functions, etc. There is no excuse to have an allocated bare pointer anymore.

>>32
Dung-a-lung-a-lung!

>>35 since allocated memory using new is automatically released
Oh hi there, memory leaks.

>>1
Too little info. Where does the data for the object come from?

If you expect the data for the object to be bad from time to time (like when it's coming directly from user input), then I'd wager wrapping the construction in a builder class would be appropriate.

If you're thinking of doing assertions for debugging purposes  (checking pre- and post-conditions) then just throw an exception.

Ain't sepples great?

>>38
If you're thinking of doing assertions for debugging purposes  (checking pre- and post-conditions) then just throw an exception.
No, no, no. Fucking Java programmers fucking everything up.

>>40
Quoting the C++ FAQ Lite Section 17:
[17.2] How can I handle a constructor that fails?
Throw an exception. (...)

[17.12] Exception handling seems to make my life more difficult; clearly I'm not the problem, am I??
(...) Here are some "wrong exception-handling mindsets" in no apparent order:
(...)
Confusing logical errors with runtime situations: For example, suppose you have a function f(Foo* p) that must never be called with the NULL pointer. However you discover that somebody somewhere is sometimes passing a NULL pointer anyway. There are two possibilities: either they are passing NULL because they got bad data from an external user (for example, the user forgot to fill in a field and that ultimately resulted in a NULL pointer) or they just plain made a mistake in their own code. In the former case, you should throw an exception since it is a runtime situation (i.e., something you can't detect by a careful code-review; it is not a bug). In the latter case, you should definitely fix the bug in the caller's code. You can still add some code to write a message in the log-file if it ever happens again, and you can even throw an exception if it ever happens again, but you must not merely change the code within f(Foo* p); you must, must, MUST fix the code in the caller(s) of f(Foo* p).

>>41
Good job retard, read my post from earlier: >>14

The whole point is to fix the code in the CALLERS. The best way to accomplish that (which the faq fails to mention) is to abort().

Also, I completely disagree with the FAQ about throwing an exception when a null pointer might have resulted from user input. That's plain fucking brain dead. Input validation should happen WAY sooner and should be very encapsulated; throwing exceptions is very much not the right way to handle bad user input.

>>42
Don't forget the FQA.

http://yosefk.com/c++fqa/

>>42
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()?

May I ask how, the fuck, do you expect to gather debugging information after that? Have you ever used a logging facility of any kind, besides stderr? Do you write anything else then toy programs?

Also, I completely disagree with the FAQ about throwing an exception when a null pointer might have resulted from user input. That's plain fucking brain dead.

It's just like I'm in CS III again!

It's just like I'm in CS III again!
Welcome to /prog/

>>45
What? But I haven't left /prog/ since 2004!

>>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*.

Dammit /prog/, why do you make me argue on the internets?

Who ever claimed you have to debug code before shipping it? It's not like end-users mind helping you as free beta-testers!

>>47-49
No genius, you never call abort() directly; you assert() to verify the arguments.
Really? Tell me more.

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.
How is it easier than catching the exception, writing down all the information you can for debugging and showing an error dialog?

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.
http://www.ibm.com/developerworks/linux/library/l-cppexcep.html

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.
You can do that with exceptions too with an equal amount of work. It also means you'll be using a C++ facility instead of a C workaround in C++!
That's why exceptions exist in the first place: to replace assert() and abort() with an alternative which can provide more information.

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...)
You don't have the appropriate tools to develop with C++ if that's a problem.

Everyone in the industry used abort() and assert() in C++ because:
a) Most people didn't bother to learn to use them and carried over their C habits.
b) Everyone who bothered had been bitten by poor compiler support (at the time)
c) No tools
Again: abort() and assert() were used instead as a workaround.
Today all those points are moot but somehow everyone sticks to the notion that C++ exceptions aren't worth using because they aren't Java exceptions.

C++ exceptions don't have the features of Java exceptions but they're heaps better than the C workaround you're using.

You know what's sad? You probably mean well but you're stuck with people who don't know any better. We wouldn't have this argument if Sepples wasn't a pile of pre-standard legacy code, bad practices and emergent features (i.e. a humongous pile of shit). It's a fucking mess stretched over the years.

>>52
a) Most people didn't bother to learn exceptions and carried over their C habits.
b) Everyone who bothered had been bitten by poor compiler support for exceptions (at the time)
Fixed.

>>53

a) Sepples sucks ass.

Fixed.

Plato imagines a group of people who have lived chained in a cave all of their lives, facing a blank wall. The people watch shadows projected on the wall by things passing in front of a fire behind them, and begin to ascribe forms to these shadows. According to Plato, the shadows are as close as the prisoners get to seeing reality. He then explains how the philosopher is like a prisoner who is freed from the cave and comes to understand that the shadows on the wall are not constitutive of reality at all, as he can perceive the true form of reality rather than the mere shadows seen by the prisoners.

I was browsing the bookstore today, and I saw this:
http://www.amazon.co.uk/Programming-Principles-Practice-Using-C/dp/0321543726/ref=sr_1_1?ie=UTF8&s=books&qid=1257800650&sr=8-1

Preparation for Programming in the Real World

The fucking audacity of the guy! He's a complete failure as a language designer, heaping layers of dung on older layers of dung resulting in a monumental pile of shit that no-one can understand or use "properly." Modern sepples is the real toy language, not Haskell or Lisp.

>>55
cave = sepples, and philosopher = lispnik, i assume?

>>57

Wrong. Philosopher = Smalltalk-programmer.

It sems that the days of warrior-poets and philosopher-kings are long gone by now.

>>55
I've read SICP. Sepples just pays the bills.

>>52
You can do that with exceptions too with an equal amount of work. It also means you'll be using a C++ facility instead of a C workaround in C++!
Holy shit dude. You tell me sepples' exception support is better by pointing me to a processor-and-compiler-and-kernel-specific hack to get stack traces. The article has 'tricks for Linux' in the title for crying out loud. And that's not a workaround...

Yes, it's the same thing I was talking about with abort(). At least I admit that it's a hack! None of this exception support you rave about is even widely supported, let alone standardized. We don't all program for x86. We don't all program for Linux. We don't all compile with GCC or Intel. Keep drinking that kool-aid buddy.

That's why exceptions exist in the first place: to replace assert() and abort() with an alternative which can provide more information.
You haven't given more information at all! All you've proven is that the same hacks I've been using to get stack traces with abort() are available with exceptions (in an even more convoluted way, in the constructor to all your user-defined exceptions; good luck doing that with std::logic_error, std::range_error, etc.)

c) No tools
Why the fuck should you need tools to interpret something that is supposed to be a standard feature of the language? What possible tools could these be? I need a p-and-c-and-k-specific library for stack traces? I need the app to actually be hooked up to the debugger? What the fuck?

This is why people don't use sepples exceptions. They are just plain incomplete.

Also, you keep saying assert() is a workaround. What a joke.

>>55
so basically.
HURRRR DURRR LOOK AT ME, I"M SUCH A FREE THINKING UBER COOL REBEL
Plato

exception handling is easy and complete in C.
much better than sepples.
if(function == -1)
   err(1, "function()");

NO EXCEPTIONS

>>61

Why are so many delusional people on the internet?

don't feed constructors incorrect data, dipshit.

>>64
are you telling me that you think that quote from Plato isn't an incredibly egotistical crock of shit?
philosophy fags like you (and him) are incredibly shallow

>>66
Plato will still be remembered in 300 years.  You will not.

>>67
thats deep bro

>>67
how pessimistic.
for all you know, i could be bill gates

>>69
how pessimistic.
for all you know, i could be steve ballmer

DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS

>>69
not if he's bill gates

>>70
am i the only one who thinks ballmer is awesome?

>>72
yup

>>72
Yes, Steve.

>>60
Holy shit dude.
Uh-huh.

You tell me sepples' exception support is better by pointing me to a processor-and-compiler-and-kernel-specific hack to get stack traces. The article has 'tricks for Linux' in the title for crying out loud. And that's not a workaround...
Stack traces are platform specific to begin with. Most OSes which support C++ development have their own API for retrieving stack traces from exceptions. If you'd like a cross-platform method then you'd need to to abstract away your platform. Sounds familiar?

Yes, it's the same thing I was talking about with abort(). At least I admit that it's a hack! None of this exception support you rave about is even widely supported, let alone standardized.
You've maybe heard of the C++ standards committee and their the `C++98 standard'. Last I heard, most of it has been implemented by many of the major available C++ compilers for a while.

We don't all program for x86. We don't all program for Linux. We don't all compile with GCC or Intel.
I'm at a loss here. What are you trying to say? I've never implied I'm talking about anything platform specific. If you are working with a platform without exception support then it's not the language that's at fault?

Keep drinking that kool-aid buddy.
Riiiiiight. Moving right along.

You haven't given more information at all! All you've proven is that the same hacks I've been using to get stack traces with abort() are available with exceptions
Now we're getting somewhere.

(in an even more convoluted way, in the constructor to all your user-defined exceptions; good luck doing that with std::logic_error, std::range_error, etc.)
If it's convoluted then you're doing it wrong. For example you don't mix user-defined and STL exceptions. You choose either and stick with it throughout your application/system/library. Just like in C, practically every non-trivial library uses it's own error handling facility. Exceptions provide a single, standardised error handling facility.

Why the fuck should you need tools to interpret something that is supposed to be a standard feature of the language? What possible tools could these be? I need a p-and-c-and-k-specific library for stack traces?
Yeah, what the fuck. Why do I need a debugger, a compiler, a text editor. Ad nauseum.

I need the app to actually be hooked up to the debugger? What the fuck?
Sigh. Java exceptions are so good basically because every application runs inside a debugger. You won't get that with a static language without OS-specific extensions. Period.

This is why people don't use sepples exceptions. They are just plain incomplete.
The point I'm trying to make is that they were incomplete a long time ago. Every dipshit with an opinion keeps reiterating an age old mantra without actually understanding what C++ exception were meant to accomplish. It's just like everyone who read a 10-year old book about C++ thinks the language is written in stone.

Also, you keep saying assert() is a workaround. What a joke.
It's a C facility, not C++. As I said, the compatibility between the two allowed developers to work around the fact that exception weren't properly implemented yet. Since they are supported by compilers available today, the reason to avoid exceptions in new applications is long gone.

>>75
Stack traces are platform specific to begin with
...because the C++ standard does not support them.

You've maybe heard of the C++ standards committee and their the `C++98 standard'
...which does not include stack traces.

Why the fuck is this so hard to understand? Languages like Java or Python include stack traces, and these are available in a portable way inside the application itself. C++ could have done this. It could have been a requirement of the standard.


Why is this so hard to understand?


If it's convoluted then you're doing it wrong. For example you don't mix user-defined and STL exceptions. You choose either and stick with it throughout your application/system/library.
Wow, this is some terrible exceptions advice. You are *always* supposed to subclass std::exception to create your own exceptions. You can't get away from built-in exceptions without getting rid of the entire STL (and replacing new so that it doesn't throw).

Exceptions provide a single, standardised error handling facility.
You mean, if you choose either STL or custom exceptions and hope every library you use does the same? Isn't this the very opposite of what you just said?

>>76
NICE TRY BUDDY, BUT YOU HAVE TO GET UP PRETTY EARLY IN THE MORNING TO TROLL ME

STOP TALKING ABOUT PROGRAMMING!!!

>>77
Ah, false claims of trolling, the last refuge of a /b/tard

>>79
nice try buddy. but im still not biting. no one could be so retarded as >>76

>>78
how about no !

Sepples is the greatest programming language ever created, because as people get fed up with how shit it is they may be inspired to create languages that are actually good.

>>78
YEAH, LET'S TALK ABOUT HOW TO RECOGNISE DIFFERENT TYPES OF TREES FROM QUITE A LONG WAY AWAY

>>83
Like a binary dicks tree?

>>82
eg ruby!

>>76
Why the fuck is this so hard to understand? Languages like Java or Python include stack traces, and these are available in a portable way inside the application itself.
You're comparing apples to oranges. C++ is a static language.
One is inside a VM which, like I said, provides a debugger. The other is a dynamic, interpreted (or byte-code compiled) language which also provides a debugger.

C++ could have done this. It could have been a requirement of the standard.
Why is this so hard to understand?

It could include that but then no compiler would've implemented it. Platform independent stack traces so close to the metal are hard to do right.

Wow, this is some terrible exceptions advice. You are *always* supposed to subclass std::exception to create your own exceptions. You can't get away from built-in exceptions without getting rid of the entire STL (and replacing new so that it doesn't throw).
Yes, except no, you are wrong. From the C++ FAQ Lite, 17.6:
If possible, you should throw instances of classes that derive (ultimately) from the std::exception class.

You mean, if you choose either STL or custom exceptions and hope every library you use does the same? Isn't this the very opposite of what you just said?
What I meant is that with the try/catch mechanism you can catch both. When programming in C you have to implement some kind of replacement try/catch for error handling and interface with custom error handling procedures of your libraries.

>>86
You are being far too flattering if you call those debuggers

You're comparing apples to oranges. C++ is a static language. One is inside a VM which, like I said, provides a debugger. The other is a dynamic, interpreted (or byte-code compiled) language which also provides a debugger.
Okay first of all, a VM is not a debugger. Second of all, what does interpreted have to do with exceptions??

Correct me if I'm wrong folks, but doesn't Lisp support stack traces even when compiled statically (to C code)?

It could include that but then no compiler would've implemented it. Platform independent stack traces so close to the metal are hard to do right.

You don't seem to understand how the stack is built. The stack is not restricted by the 'bare metal' in any way; it's a compiler construct. C stack traces are difficult to decipher because of how the compiler builds them. There is nothing that says C++ has to grow its stack the same way. It could push a freaking C string with the function name into every stack frame if it wanted. This would be extremely easy. But it doesn't. Compiled apps have complete control over how the stack grows; for example Go uses a segmented stack.

The argument about 'difficult to implement' is total bullshit. The compiler already has to add stack unwinding information, which is vastly more complicated than just getting the names of the stack frames.

You are *always* supposed to subclass std::exception to create your own exceptions.
you are wrong. From the C++ FAQ Lite, 17.6:
If possible, you should throw instances of classes that derive (ultimately) from the std::exception class.
Okay dude, I don't know what to say anymore. Are you trolling? Did you quote the wrong faq answer? Because this is not a rational debate anymore.

What I meant is that with the try/catch mechanism you can catch both. When programming in C you have to implement some kind of replacement try/catch for error handling and interface with custom error handling procedures of your libraries.
Um, no. The 'return status code' mechanism works really well, and is the most consistently used in C (it's used proportionally far more than exceptions are used in C++). Companies like Google have millions of lines of C++ code, and they do fine without exceptions.

And if a library really needs you to implement a replacement try/catch, it's really not a big deal dude. Ever integrated libpng into a project? It's pretty awesome. You just do this before you start decoding:

if (setjmp(png_jmpbuf(png_ptr))) {
  png_destroy_read_struct(&png_ptr, &info_ptr, &end_info);
  // do whatever you want here, show the user a dialog, etc
  return 0;
}

All of this is always documented very well. And if you don't like it, libpng has a simple preproc you just turn off to get plain old 'return ERROR' style error handling.

>>88
Correct me if I'm wrong folks, but doesn't Lisp support stack traces even when compiled statically (to C code)?

Yes, you can even get info about the C stack frame too, if you have some C runtime included, and copious information about the parameters and maybe even local variables of your functions in the stack frame if you compiled your functions with enough debug info (compiling is per code unit, which is most oftenly a function).