Making an Exception

re: Making an Exception

Jason — Sat, 26 Feb 2011 02:17:41 GMT

I use scopeguard for simple code that might be handled by finally in Java. I prefer it to finally because (a) the release code only ever needs to be mentioned once and (b) the release code is written immediately after the acquisition code so it's easier to maintain.

E.g.:

CDC* pDC = GetDC();

ON_BLOCK_EXIT(&CWnd::ReleaseDC, this, pDC);

The original article is at www.drdobbs.com/184403758 but I use the one by Joshua Lehrer (www.zete.org/.../scopeguard.html).

I've come across a really simple C++0x implementation using lambdas but I'm not sure where I got it from now. But it allows you to handle the example given by kaalus like this:

void f()

{

executing = true;

ON_BLOCK_EXIT([&]{

executing = false;

});

DoStuff();

}

Much more elegant and easier to read than finally.

re: Making an Exception

Leo Davidson — Sun, 13 Feb 2011 08:23:41 GMT

>> Should we be forced to wrap every single thing we use

> Yes. Yes, you should.

Expecting every single development team to make their own bespoke wrappers seems backwards.

How about the people who make Win32, the main non-RAII API we are all subjected to, do that C++ RAII wrapper for us, well and in one place, make it cover the entire API, and continue to maintain it as part of the main SDK, not as an afterthought that is updated slowly and all but abandoned when some other framework becomes the current fad?

Aside from the consolidation of effort, it'd make code and programmers a lot more interchangeable between projects and teams.

If MS cannot provide that wrapper is it reasonable to expect everyone else to provide their own?

Smart pointers and other generics are simply not enough to deal with all the weird things Win32 throws at us.

FWIW, I *do* make RAII wrappers for a lot of things (and not just resource clean-up; e.g. ensuring a threading event is set when a code block exits), and in my own code I almost never use exceptions, but I've still found myself in situations where I've sat wondering why C++ so stubbornly resists having finally blocks. It seems like a head-in-the-sand mentality to me, which is quite strange for a language that bends over backwards to support so many different programming styles (and as a result, supports Win32, which is not RAII).

re: Making an Exception

dex — Tue, 08 Feb 2011 21:17:45 GMT

Who needs finally?

That's what the lines after the catch clauses are for aren't they?

What do you mean there are some exceptions you just let through?

Then I put it to you that your supposed "finally" code is (usually) not going to make one whit of difference, you're already in a bad place.

Who uses global variables directly rather than wrapping them properly?

and yes, so far I've wrapped a fair percentage of the Win32 API, god help me...

re: Making an Exception

dex — Tue, 08 Feb 2011 21:11:30 GMT

Internationalisation in std::exception?

Use UTF-8 (or if you're really pedantic about signed char UTF-7).

A simple wrapper class can take care of the conversion if you insist on using Unicode strings or you better still use a resource string id (or equivalent) and a look-up/load operation etc. etc.

re: Making an Exception

kaalus — Tue, 08 Feb 2011 00:26:37 GMT

Finally is sorely lacking from C++. RAII is great but it only really applies to releasing resources wrapped in a class. What if e.g. I want to reliably reset a flag on exit from a function?

void f()

{

executing = true;

try

{

DoStuff();

}

finally

{

executing = false;

}

Instead of the clean code above, in C++ I would have to create a silly class that resets the flag in the destructor.

No idea why some people are so stubborn on that one. Just add finally, it's not redundant by any means.

re: Making an Exception

Diego Dagum - MSFT — Fri, 07 Jan 2011 00:01:06 GMT

I want to thank you all guys for all these comments. They certainly reconfirm once again that there's no one-size-fits-all clue for any potential problem that requires exception handling.

But that's not a fact to get frustrated: it's just some wisdom to correctly tailor, whatever the approach we take, in its right size (helpful for these contexts, harmful for another ones).

I learned a lot from you guys. Will keep posting these debates.

re: Making an Exception

S. Colcord — Mon, 03 Jan 2011 19:56:19 GMT

STL wrote:

"...with /EHsc being preferable (it's faster because it assumes that extern "C" functions won't emit exceptions - while technically permitted by the Standard, sane code should never attempt to do such a thing..."

While it would certainly be preferable to avoid this, it sometimes happens. I'm maintaining a large (several million LOC), old (25+ years) application, written in C and partially converted to C++, where the call stack regularly passes back and forth between the two. It just wouldn't be practical to try to block exceptions from crossing the language boundary. We just spent a substantial amount of time tracking down a problem that turned out to be because we were using /EHsc. I would recommend that all mixed C and C++ applications use /EHs by default, and only switch to /EHsc if they're really certain that their extern "C" functions could never let an exception escape (presumably with a catch(...) clause). Otherwise the optimizer starts silently eliding catch clauses, resulting in Release-build only crashes that can be hard to track down.

re: Making an Exception

non-unicode :( — Mon, 03 Jan 2011 08:06:51 GMT

The problem I've had with the STL exceptions is that they store the message as a byte (non-Unicode) string (or at least, std::exception::what returns a byte string). So I create my own base exception class:

class Exception

{

public:

explicit Exception(const std::wstring& message) : m_message(message)

{

}

virtual ~Exception()

{

}

const std::wstring& GetMessage() const

{

return m_message;

}

protected:

std::wstring m_message;

};

re: Making an Exception

Marat Abrarov — Sat, 01 Jan 2011 23:22:16 GMT

What about boost::asio && boost::system::error_code?

Does anybody remember its trick with exceptions vs error codes? I think it's a great example of how it must be written in "modern C++ style" - use error codes (result codes) for code with (often) variable results (i.e. boost::system::error_code) and write exception-based wrappers for those users who don't need error codes. It's very simple (but mostly reasonable for libraries).

And, of course, sometimes error codes can't be used (we all know this cases - constructors, operators' overloading etc).

re: Making an Exception

Gary Price — Sat, 01 Jan 2011 13:27:43 GMT

The best reason I know not to allocate memory when throwing exceptions is to avoid a crash if the heap is corrupt, leading to a nasty debugging situation where you can't get information about what went wrong. The same thing goes for freeing memory. It also applies to operations that you might undertake to document what went wrong - for example dumping a file of information. All should be done without involving the heap.