having "throw" write to a file before actually throwing

J

Jacek Dziedzic

Hi!

<OT, background>
I am in a situation where I use two compilers from different
vendors to compile my program. It seems that recently, due to
a misconfiguration, library conflict or my ignorance, with one
of the compilers I am having trouble related to libuwind.so,
which, to my knowledge, deals with the intricacies of unwinding
the stack upon an exception. Executables compiled with this
compiler crash with a SEGV after throw(), never reaching catch(),
going through likes of _Unwind_ApplyVirtualRule just before they
die. Perhaps it's because throw()'s are located in a library
and are "caught()" in the main program.
</OT>

Now, for the C++ question...

Anyway, before I resolve this issue I'd like to obtain
a behaviour as-if "every throw statement wrote to a log file,
before actually throwing". Is there a kludge way to do it?

I tried an ugly trick of re#defining throw to something like
Assert(...),throw
but then the preprocessor replaces the word "throw" in
exception specifications too.

Trying to wrap all throws into some throw_ functions
seems like a lot of work. Perhaps there's an easy solution?

TIA,
- J.
 
R

Rolf Magnus

Jacek said:
Hi!

<OT, background>
I am in a situation where I use two compilers from different
vendors to compile my program. It seems that recently, due to
a misconfiguration, library conflict or my ignorance, with one
of the compilers I am having trouble related to libuwind.so,
which, to my knowledge, deals with the intricacies of unwinding
the stack upon an exception. Executables compiled with this
compiler crash with a SEGV after throw(), never reaching catch(),
going through likes of _Unwind_ApplyVirtualRule just before they
die. Perhaps it's because throw()'s are located in a library
and are "caught()" in the main program.
</OT>

Now, for the C++ question...

Anyway, before I resolve this issue I'd like to obtain
a behaviour as-if "every throw statement wrote to a log file,
before actually throwing". Is there a kludge way to do it?

You could let the exception object that you are about to throw do that in
its constructor.
 
J

Jacek Dziedzic

Jacek said:
That's interesting, thanks!

.... but then again, if I use __LINE__, __PRETTY_FUNCTION__
and things like that, they will refer to the constructor
of the root exception object, not the place of the throw.

What I really want is to have a log of where in my source
which exceptions occurred when.

thanks,
- J.
 
M

mlimber

Jacek Dziedzic wrote:
[snip]
Anyway, before I resolve this issue I'd like to obtain
a behaviour as-if "every throw statement wrote to a log file,
before actually throwing". Is there a kludge way to do it?

I tried an ugly trick of re#defining throw to something like
Assert(...),throw
but then the preprocessor replaces the word "throw" in
exception specifications too.

Trying to wrap all throws into some throw_ functions
seems like a lot of work. Perhaps there's an easy solution?

Don't use exception specifications
(http://www.gotw.ca/publications/mill22.htm), and then your macro will
work. Alternately, use a macro for your actual throws, e.g.:

#define THROW( E, p ) \
{ \
E e_( p ); \
std::eek:fstream log_( "log.txt" ); \
if( log_ ) log_ << e_.what() << std::endl; \
throw e_; \
}

class MyException : public std::exception { ... };

THROW( MyException( "Some error text" ) );

Cheers! --M
 
M

Michiel.Salters

Jacek said:
Hi!

<OT, background>
I am in a situation where I use two compilers from different
vendors to compile my program. It seems that recently, due to
a misconfiguration, library conflict or my ignorance, with one
of the compilers I am having trouble related to libuwind.so,
which, to my knowledge, deals with the intricacies of unwinding
the stack upon an exception. Executables compiled with this
compiler crash with a SEGV after throw(), never reaching catch(),
... Perhaps it's because throw()'s are located in a library
and are "caught()" in the main program.
</OT>

Not really OT. The exception mechanism is implementation-specific.
If you mix two compilers, you get Undefined Behavior like this. Don't
expect it to work.
Now, for the C++ question...

Anyway, before I resolve this issue I'd like to obtain
a behaviour as-if "every throw statement wrote to a log file,
before actually throwing". Is there a kludge way to do it?

No. Keep in mind that you could even have a throw (1); not to
mention a plain throw;

Furthermore, new throws as well. That's not a throw statement at all,
yet you's suffer the same effects.

HTH,
Michiel Salters
 
J

Jacek Dziedzic

mlimber said:
Don't use exception specifications
(http://www.gotw.ca/publications/mill22.htm), and then your macro will
work.

I know not to use them, but system headers files do use them.
Alternately, use a macro for your actual throws, e.g.:

#define THROW( E, p ) \
{ \
E e_( p ); \
std::eek:fstream log_( "log.txt" ); \
if( log_ ) log_ << e_.what() << std::endl; \
throw e_; \
}

class MyException : public std::exception { ... };

THROW( MyException( "Some error text" ) );

Yes, but that's much work replacing the throws.

For now I have automatically replaced all instances
of "throw" with "logged throw" and did
#define logged \
std::cerr << __FILE__ << "\n" << __LINE__ << std::endl,

Works for now...

thanks,
- J.
 
M

mlimber

Jacek said:
I know not to use them, but system headers files do use them.


Yes, but that's much work replacing the throws.

For now I have automatically replaced all instances
of "throw" with "logged throw" and did
#define logged \
std::cerr << __FILE__ << "\n" << __LINE__ << std::endl,

Works for now...

Ok, but that is essentially the same solution I proposed and requires
the same amount of work to find/replace all the instances.

Cheers! --M
 
J

Jacek Dziedzic

Not really OT. The exception mechanism is implementation-specific.
If you mix two compilers, you get Undefined Behavior like this. Don't
expect it to work.

That I know. The problem is that my issue arises even when
I compile _both_ the library and the main program with the
_same_ compiler, with the _same_ options. I suspect that, because
the main program has parts in FORTRAN, it pulls some i/o
librariess that in turn pull a different version of the unwind
library than the one my library uses. But it's just a guess.

No. Keep in mind that you could even have a throw (1); not to
mention a plain throw;

Yes, I was rather interested in "ugly preprocessor tricks".
Furthermore, new throws as well. That's not a throw statement at all,
yet you's suffer the same effects.

Right. Yet I am only interested in the exceptions I throw
myself, so that wouldn't bother me.

thanks,
- J.
 
J

Jacek Dziedzic

mlimber said:
Ok, but that is essentially the same solution I proposed and requires
the same amount of work to find/replace all the instances.

Well, almost. With my method, since I don't use 'throw'
in any other context than for throwing exceptions, I could use
cat *.cpp *.h | sed "s/throw/logged throw/g"
to have it replaced.

Your method has the disadvantage of havind to add the ")"
after the exception name, which in many cases was not on the
same line as the "throw" keyword. That sounded a little tricky
for me to handle :).

thanks,
- J.
 
M

matthewlimber

Jacek said:
Well, almost. With my method, since I don't use 'throw'
in any other context than for throwing exceptions,

Now wait a minute. In the OP, you complained about the macro
invalidating exception specifications. Do you use them or not?
I could use
cat *.cpp *.h | sed "s/throw/logged throw/g"
to have it replaced.

Your method has the disadvantage of havind to add the ")"
after the exception name, which in many cases was not on the
same line as the "throw" keyword. That sounded a little tricky
for me to handle :).

That's just mechanics. You could use regular expressions (or some other
utility) to do the more complex substitutions. My point remains that
you must do the same number of substitutions.

Cheers! --M
 
J

Jacek Dziedzic

(e-mail address removed) napisał(a):
Now wait a minute. In the OP, you complained about the macro
invalidating exception specifications. Do you use them or not?

As I said -- I don't use them, but the system/compiler
header files do. Like when I redefined "throw" I got a
lot of errors from .h files that weren't mine and the
errors pointed to exception specifications.

In fact all my exception class names begin with 'E',
so it was even easier -- I have replaced "throw E".
That's just mechanics. You could use regular expressions (or some other
utility) to do the more complex substitutions. My point remains that
you must do the same number of substitutions.

Yes, I agree. Let's say it has the same time complexity, albeit
with a bigger prefactor, because I don't know how to use regexps
properly :). Plus your method is cleaner and mine is not even
guaranteed to work, afair, because it redefines a keyword.

- J.
 
B

BobR

Jacek Dziedzic wrote in message
... but then again, if I use __LINE__, __PRETTY_FUNCTION__
and things like that, they will refer to the constructor
of the root exception object, not the place of the throw.

What I really want is to have a log of where in my source
which exceptions occurred when.
thanks,
- J.

Maybe this will give you an idea.


// --- std includes ---
#include <iostream> // C++
#include <ostream> // std::endl
#include <string>
// #include <sstream> // for __LINE__ conversion to string
#include <stdexcept>

class MyError : public std::runtime_error { public:
MyError(std::string const &msg = "") : std::runtime_error(msg){}
};
// --------------------------------------

void f() throw( MyError ){
std::string Msg( __FILE__": my message"
"\n Thrown from deep within ");
Msg += __PRETTY_FUNCTION__; // non-portable (GCC)
throw MyError( Msg );
// -- or (more portable):
// throw MyError(__FILE__": my message"
// "\n Thrown from deep within f()" );
return;
}

int main(){
try{ f(); }
catch( MyError const &x){
std::cout<<"MyError: "<<x.what()<<std::endl;
// throw; // re-throw, kill the program
}
return 0;
} // main()end
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
474,262
Messages
2,571,056
Members
48,769
Latest member
Clifft

Latest Threads

Top