Google's Go & Exceptions

"Jérôme M. Berger" jeberger at free.fr
Tue Jan 26 14:49:34 PST 2010


Justin Johansson wrote:
> (1) For some reason (possibly valid only in an historic context), I have
> this great aversion to throwing exceptions from inside C++ constructors.
>  From memory, I once threw an exception from inside a constructor
> with an early C++ compiler and wound up with stack corruption or
> something like that, and consequently I developed the practice of
> forever more avoiding throwing from inside a C++ constructor.
> 
> (2) Also, and this might be urban myth, I'm of the belief that a try
> block does not come for free at runtime even if an exception is not
> thrown (i.e. there's a cost to establishing the try block itself),
> that for performance critical code the old fashion return and check
> error code idiom is faster.
> 
> I wonder if our resident C++ compiler writer can shine any truth on (1).
> 
> With (2), can people either confirm (A) that it is true that try{}
> is not completely and absolutely free, or (B) that (2) is urban myth.
> 
	Throwing exception inside constructors should be avoided because
then the destructor is never called and you risk leaking like crazy.

	Regarding point (2), it depends on your compiler. Recent g++
versions may use something called "DWARF exception unwinding" which
costs nothing so long as you don't throw. Older versions (or when
there is a risk that some stack frames won't be in the right format,
like on windows) use setjmp and longjmp. In that case, the try block
costs a setjmp (plus whatever is required for making the jmp_buf
thread-local). I don't know how other compilers handle it.

		Jerome
-- 
mailto:jeberger at free.fr
http://jeberger.free.fr
Jabber: jeberger at jabber.fr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20100126/b8c08c52/attachment.pgp>


More information about the Digitalmars-d mailing list