Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++ Exceptions: Under the Hood (2013)

monkeywritescode.blogspot.com

Post reply on HN
Print view View original

41–50 of 116 posts

Re: C++ Exceptions: Under the Hood (2013)

#41

Post by ilammy »

dataflow wrote: post #40
WalterBright wrote: post #14

Working with and implementing C++ exceptions for 30 years now, including implementing exception handling for Windows, DOS extenders, and Posix (all very different), and then re-implementing them for D, I have sadly come to the conclusion that exceptions are a giant mistake. 1. they are very hard to understand all the way down 2. they are largely undocumented in how they're implemented 3. they are slow when thrown 4.…

Don't you need exceptions though? How do you terminate arbitrary operations without exceptions? Like say you call an algorithm (like std::sort) and during a callback (e.g. in the comparator) you decide to cancel the operation (perhaps user-requested). With exceptions it's easy; you just throw an exception and then catch it. No need to touch or even know the intermediate callers. But without exceptions what do you do?…

But with exceptions what do you do? You have to go modify or reimplement the source code of every intermediate function to be correct and safe when an exception is thrown at every point where it can be thrown, which is a giant waste of effort at best, and in reality a likely vector for introducing code duplication, brittleness, and bugs.

The point is, retrofitting exceptions onto existing codebase is a lot of pain.

Interruptible functions have the API they have because they have been designed with exceptions in mind for interruptions. If there were no exceptions, the callbacks would have had a different API. A special return value could be used to signal an interruption.

Re: C++ Exceptions: Under the Hood (2013)

#42

Post by [deleted] »

dataflow wrote: post #40
WalterBright wrote: post #14

Working with and implementing C++ exceptions for 30 years now, including implementing exception handling for Windows, DOS extenders, and Posix (all very different), and then re-implementing them for D, I have sadly come to the conclusion that exceptions are a giant mistake. 1. they are very hard to understand all the way down 2. they are largely undocumented in how they're implemented 3. they are slow when thrown 4.…

Don't you need exceptions though? How do you terminate arbitrary operations without exceptions? Like say you call an algorithm (like std::sort) and during a callback (e.g. in the comparator) you decide to cancel the operation (perhaps user-requested). With exceptions it's easy; you just throw an exception and then catch it. No need to touch or even know the intermediate callers. But without exceptions what do you do?…

[deleted]

Re: C++ Exceptions: Under the Hood (2013)

#43

Post by dataflow »

ilammy wrote: post #41
dataflow wrote: post #40

Earlier quoted context omitted.

Don't you need exceptions though? How do you terminate arbitrary operations without exceptions? Like say you call an algorithm (like std::sort) and during a callback (e.g. in the comparator) you decide to cancel the operation (perhaps user-requested). With exceptions it's easy; you just throw an exception and then catch it. No need to touch or even know the intermediate callers. But without exceptions what do you do?…

But with exceptions what do you do? You have to go modify or reimplement the source code of every intermediate function to be correct and safe when an exception is thrown at every point where it can be thrown , which is a giant waste of effort at best, and in reality a likely vector for introducing code duplication, brittleness, and bugs. The point is, retrofitting exceptions onto existing codebase is a lot of pain.…

No you don't, you're massively exaggerating. The standard library already has at least basic if not strong exception-safety all over it. And RAII is pretty darn standard practice and guarantees basic exception safety in your own code too. You don't need strong exception safety here, just basic is sufficient for most such cases.

Go try this with std::sort (or std::adjacent_find or whatever) and tell me which of their implementations you had to modify.

Re: C++ Exceptions: Under the Hood (2013)

#44

Post by ilammy »

dataflow wrote: post #43
ilammy wrote: post #41

Earlier quoted context omitted.

But with exceptions what do you do? You have to go modify or reimplement the source code of every intermediate function to be correct and safe when an exception is thrown at every point where it can be thrown , which is a giant waste of effort at best, and in reality a likely vector for introducing code duplication, brittleness, and bugs. The point is, retrofitting exceptions onto existing codebase is a lot of pain.…

No you don't, you're massively exaggerating. The standard library already has at least basic if not strong exception-safety all over it. And RAII is pretty darn standard practice and guarantees basic exception safety in your own code too. You don't need strong exception safety here, just basic is sufficient for most such cases. Go try this with std::sort (or std::adjacent_find or whatever) and tell me which of their…

Well but of course! These functions are already implemented with basic exception safety in mind. What if they weren't? This is exactly the same situation as a function that has

    callback();
which cannot be changed into

    if Err(error) = callback() {
        return error;
    }
because that would break some invariants.

Changing return type from "void" into some "result" is a mechanical change.

Re: C++ Exceptions: Under the Hood (2013)

#45

Post by cjfd »

WalterBright wrote: post #14

Working with and implementing C++ exceptions for 30 years now, including implementing exception handling for Windows, DOS extenders, and Posix (all very different), and then re-implementing them for D, I have sadly come to the conclusion that exceptions are a giant mistake. 1. they are very hard to understand all the way down 2. they are largely undocumented in how they're implemented 3. they are slow when thrown 4.…

"has anyone yet found a legitimate use for throwing an `int`?"

I could image throwing an int when writing a shell utility and throwing the return value of main as an int but I suppose doing that usefully would be pretty rare. Usually one cares more about whether a shell utility is successful or not not so much about the precise reason it failed. So, while I could imagine doing that, I don't see myself going for that option too likely.

Re: C++ Exceptions: Under the Hood (2013)

#46

Post by erik_seaberg »

WalterBright wrote: post #38
winstonewert wrote: post #37

Earlier quoted context omitted.

So that sounds like the way invalid floating point operations give NaN, and then the NaN propagates everywhere. I've always found this super annoying because its often hard to figure out where the NaN comes from. Does your solution differ from this in a way that's less annoying?

The FPU does not include the source in the NaN, but that doesn't mean your own objects can't. What I do is have the error reported at the source, and then return the poisoned object. A better way would possibly be put the error message in the poisoned object, and report the error somewhere up the call stack.

What are the return values from a poisoned object’s methods? Does a poisoned vector have a poisoned integer as its size?

Re: C++ Exceptions: Under the Hood (2013)

#47

Post by dataflow »

ilammy wrote: post #44
dataflow wrote: post #43

Earlier quoted context omitted.

No you don't, you're massively exaggerating. The standard library already has at least basic if not strong exception-safety all over it. And RAII is pretty darn standard practice and guarantees basic exception safety in your own code too. You don't need strong exception safety here, just basic is sufficient for most such cases. Go try this with std::sort (or std::adjacent_find or whatever) and tell me which of their…

Well but of course! These functions are already implemented with basic exception safety in mind. What if they weren't? This is exactly the same situation as a function that has callback(); which cannot be changed into if Err(error) = callback() { return error; } because that would break some invariants. Changing return type from "void" into some "result" is a mechanical change.

As I already explained: RAII is pretty darn standard practice and guarantees basic exception safety in your own code too. The music is already there and people are already dancing to it.

> What if they weren't?

Obviously the language wasn't designed for rebels. The implicit understanding with tools is that you use them the way they're meant to be used. Only in that case do you get to assume you'll reap the benefits they claim to provide. If you insist on deliberately dancing to a different tune, then you get exactly what you asked for. You can't drive against traffic and then complain people run into you.

Re: C++ Exceptions: Under the Hood (2013)

#48

Post by jcelerier »

cecilpl2 wrote: post #22

> When the personality function doesn't know what to do it will invoke the default exception handler, meaning that in most cases throwing from a nothrow method will end up calling std::terminate. This is an interesting tidbit that cost me a week of debugging recently - a try/catch block at the top of the call stack wasn't catching an exception. We set up an exception handler that calls main in a try/catch block, so t…

How can that take a week to debug ? gdb would stop at the std::terminate call in your dtor, and catch throw would allow you to see exactly where the exception was thrown

Re: C++ Exceptions: Under the Hood (2013)

#50

Post by [deleted] »

Iwan-Zotow wrote: post #23
WalterBright wrote: post #20

Earlier quoted context omitted.

P.S. I implemented Structured Exception Handling for Win32, with help from a couple very smart people. Microsoft completely changed it for Win64, and the documentation on it is completely unhelpful to nonexistent.[1] I simply gave up on it. D on Win64 uses the exception handling mechanism I invented for the 32 bit DOS extender from the old Zortech days. It works fine, except that it cannot interact with C++ exception…

Ah, Zortech C++. That indeed brings back some memories. Walter, what do you think about Herb Sutter "new" C++ exceptions (which is basically about throwing an int/a word) ?

[deleted]
Post reply on HN