How is C++ try/catch different than C setjmp/longjmp?

Question

I was aware of exception handling in C++ using the try and catch blocks. I wondered if this functionality was there in C. So, now I know that basic error handling in C is done by setjmp/longjmp.

Since setjmp/longjmp isn't present in C++ , Can one assume that try/catch is better? In what ways???

I could implement a try/catch functionality in C using setjmp/longjmp. How is that different??

*basic error handling in C is done by setjmp/longjmp* Virtually nobody uses `setjmp` and `longjmp`. Most of the things you state in your "question" are wrong. — cnicutar, Feb 16 '13 at 20:19
There are many who would argue that error handling is much better in C. You cannot make the assumptions that you are making. — William Pursell, Feb 16 '13 at 20:19
There's not built-in functionality in C to unroll the stack as done in C++ on exceptions. You have to implement this yourself (or use unportable compiler extensions). — Some programmer dude, Feb 16 '13 at 20:20
Most C error handling is done with returning a success/failure value and a variable something like errno. — Linuxios, Feb 16 '13 at 20:27
The original "x is better than y" title is argumentative, but the question itself is valid. Voting to reopen. — Drew Dormann, Feb 16 '13 at 20:30
@cnicutar: Compilers use setjmp/longjmp, OS components transfer control like that, too. So most of the things you state in your comment are wrong. — , Feb 16 '13 at 20:54
@VladLazarenko Don't want to get into an argument but I must insists: error handling *is not done using setjmp*. Won't argue about compilers because I don't know about them. However, if by "OS components" you mean the kernel, well at least for Linux there are only a few, exotic references to anything like "setjmp". There are even many comments "the kernel doesn't have proper setjmp support". — cnicutar, Feb 16 '13 at 21:02
@VladLazarenko setjmp is very hard to maintain, because of locking and resource allocation aberrations. Typical "c" error handling is done via `if (!it_works) goto error;`. The seminal TLPI also warns sternly: *Avoid setjmp() and longjmp() where possible* after describing all manners and ways in which you get screwed by an optimizing compiler when using `setjmp`. — cnicutar, Feb 16 '13 at 21:03
@BoPersson That's a silly comment; you can't build a bicycle out of bananas. You can build exception handling on `setjmp/longjmp`. They are much more closely related than bicycles and bananas. — Kaz, Jul 31 '17 at 17:54
**voted to reopen** Though it uses the word "better", this is mostly a technical question that can be answered without resorting to opinions or extended debate. `setjmp/longmp` has certain semantics; `try/catch` in C++ has certain semantics. We can draw parallels where they overlap and point out differences. — Kaz, Jul 31 '17 at 17:55

score 4 · Answer 1 · answered Feb 16 '13 at 20:24

I think the main difference is that try/catch is aware of the objects on the stack and know how to call dtors for objects allocated on the stack, which setjmp does nothing with this.

Also, the user interface is much richer, you can define several exception types and behaves differently based on that

score 4 · Answer 2 · answered Feb 16 '13 at 20:25

4

try/catch will account for RAII. All objects that leave scope will be properly destroyed.

setjmp/longjmp will not.

answered Feb 16 '13 at 20:25

Drew Dormann

59,987
13
123
180

score 2 · Answer 3 · answered Feb 16 '13 at 20:50

Despite the missing language features like RAII etc., setjmp/longjmp is fundamentally different from the mechanism used for throwing/catching exceptions. These days, exceptions are handled using zero-cost approach where the overhead is encountered if and only if the exception is actually thrown, and otherwise there is no overhead. Since the assumption is that in a good application exception are not generally thrown, it is called a "zero cost". With setjmp/longjmp, you will be setting the jump point/context every time you "enter a try block". Therefore, there will be a lot of runtime overhead just to set the jump points. Back in a day, exceptions were implemented using setjmp/longjmp (by compilers, with RAII and all other stuff that other people stated as "missing" — so you can see why their answers are not entirely correct), so in theory you can achieve the same, but it will be far worse in terms of performance. For more details on exception handling implementation please refer to Itanium C++ ABI: Exception Handling.

All of the zero-cost exception-handling protocols I know of require a static variable per thread. Although the execution-time cost of maintaining such a variable are slight, it does introduce a level of coupling between the compiler and any underlying task-switching system (even cooperative task-switchers) which could be avoided when using a setjmp-based approach. — supercat, Mar 21 '13 at 18:23

score 0 · Answer 4 · answered Feb 16 '13 at 21:40

While setjmp/longjmp may or may not handle destructors, that's not the important difference from a design perspective. What matters is that when you throw an exception you don't know or care where it's going to be handled. The implementation walks the call stack until it finds a catch clause that can handle the thrown type or until it reaches the top of the stack; in the latter case the program aborts.

score -2 · Answer 5 · answered Feb 16 '13 at 20:23

-2

I could implement a try/catch/finally functionality in C using setjmp/longjmp. How is that different??

That's the answer to the question (you don't have to do it by yourself).

answered Feb 16 '13 at 20:23

Alien

52
3

No, it is not. Being able to implement exception mechanism using `setjmp/longjmp` does not answer how it is actually implemented. And it is definitely not implemented `setjmp/longjmp` whenever possible. – Feb 16 '13 at 20:56
I was not answering the original question but rather answering a particular question he made inside the details. In my opinion the top answers already did a good job. – Alien Feb 16 '13 at 21:05

How is C++ try/catch different than C setjmp/longjmp?

5 Answers5