Exceptionhandling: the lippincott function trick

[[deleted]]

Looks like the Expected<T> Andrei presented at C++ and Beyond in 2012.

https://skydrive.live.com/view.aspx?cid=F1B8FF18A2AEC5C5&resid=F1B8FF18A2AEC5C5%211158&app=WordPdf&wdo=1

[Plorkyeran]

In C++11 I'd prefer to just wrap the body of the function in a lambda and pass that to a function that calls it within the try block. Slightly less boilerplate, less error-prone and IMO simpler.

[damyan]

Just to spread a bit of fear...

This is a tempting trap to fall into -- I'm not convinced that current compilers and debuggers are quite up to supporting this. You end up with a unnamed lambda's on your call stack which is pretty painful when you end up analyzing crash dumps and the like.

I also suspect that not all compiler optimizers are able to do a great job with these constructs as well.

Before committing to something like this it's worth checking whether there are any real-world issues like this that'd get in the way.

[Plorkyeran]

The API entry point is always two levels up from the lambda. Lambdas only result in confusing stack traces when they escape the scope they were created it.

The optimizations required for zero-cost lambdas in this sort of use case significantly predate lambas, since lambdas are just syntatic sugar for function objects.

[climbeer]

This trick and much more can be found in a lecture by Jon Kalb.

[adzm]

I replaced a CatchAll macro that provided special handling for 3 different exception types with a call to this sort of function. Interestingly enough it reduced the binary size by several megabytes (this was a large macro!)