Hello! On Wed, Jan 24, 2007 at 12:50:21PM +0100, Chris Dams wrote:
First of all, libraries should not be spamming std{out,err}.
Surely they should not be "spamming" it. However, this code is mainly present to guard the code integrity.
Code integrity is not a good excuse for doing weird annoying things.
I.e., preventing that someone is going to unwittingly delete some line, or some such thing.
Yep, some badly designed software used to annoy people with silly questions ("Are you really sure you want to run this program?") and/or error messages("Fatal error: success"). I don't think GiNaC should do such things. (I admit that my patch does not make the error message better, but at least it allows user/application to ignore it).
So it really should never be executed.
In reality such "this should never happen" code does get executed, for instance: "Internal error: statement in file ./real/conv/cl_R_to_double.cc, line 55 has been reached!! Please send the authors of the program a description how you produced this error!"
I do not see what benefit exceptions bring to this situation.
Consider a program which uses GiNaC as an optional add-on, e.g., by dlopen()'ing it (or some wrapper library). For such a program libginac's initialization failure may not be a fatal error. If GiNaC signals such a failure with exit() the program has no chance to handle the error in a graceful manner. On the other hand, it is easy to catch an exception and take some sensible action (do the whole calculation numerically, or at least save the data before bailing out, etc). exit() from a library is EVIL.
It could only force the compiler to insert error handling code all over the place where really none is needed.
OK, let's get rid of this check at all.
Noone should be catching this exit.
I don't agree with you (see above).
Instead, if it is called, the code should be fixed.
Sure. But exit() is not really debugger-friendly anyway. Best regards, Alexei -- All science is either physics or stamp collecting.