Emulating exceptions in C: a case study • Hacker News Board

Re: Emulating exceptions in C: a case study

#21

Post by rwmj » Thu, Aug 27, 2015, 5:00 PM UTC

halayli wrote: post #20

Exceptions are not about going from one place to another. It's about unwinding the stack properly and calling the destructors of variables on the stack. This is not a close emulation at all.

While I'm not saying this is a good idea, you can combine a pool allocator with longjmp exceptions to get an approximation of unwinding. It requires that you are very careful about structuring your code, but I once wrote a whole web server this way: http://git.annexia.org/?p=rws.git;a=tree (using: http://git.annexia.org/?p=c2lib.git;a=tree ).

Re: Emulating exceptions in C: a case study

#22

Post by markbnj » Thu, Aug 27, 2015, 5:08 PM UTC

itsuart wrote: post #7

I think exceptions are very bad idea. Not nearly as bad as implicit nullability but comparable. Hacky emulations of exceptions... Well I don't want to be near such code. But that was interesting read non the less, thanks OP.

I agree it was an interesting read. Haven't thought about setjmp and longjmp in many years.

>> I think exceptions are very bad idea.

There are many cases, API implementations for example, where I cannot think of a better solution. Packing result codes into returned data, using return values, using global state, using passed state buffers, all those approaches are worse, imo, and lead to less readable and maintainable code. What's your preferred alternative?

Re: Emulating exceptions in C: a case study

#23

Post by itsuart » Thu, Aug 27, 2015, 6:03 PM UTC

markbnj wrote: post #22

itsuart wrote: post #7

I think exceptions are very bad idea. Not nearly as bad as implicit nullability but comparable. Hacky emulations of exceptions... Well I don't want to be near such code. But that was interesting read non the less, thanks OP.

I agree it was an interesting read. Haven't thought about setjmp and longjmp in many years. >> I think exceptions are very bad idea. There are many cases, API implementations for example, where I cannot think of a better solution. Packing result codes into returned data, using return values, using global state, using passed state buffers, all those approaches are worse, imo, and lead to less readable and maintainable…

In Haskell I use Maybe's, Either's and their ilk (packing result code in returned data I guess?), in C - your usual boolean return values like this: bool parse_literal (ParsingState* state, LiteralValue* pResult).

In Java/C# I have to use what other people are using :)

My dislike of exceptions (as well as errno and Set/GetLastError) is due their masking, hiding error conditions and situations. And I prefer everything to be stated clearly. Including error handling code (answer to 'did I handled all possible failures of calling this?' should be instant).

Unfortunately proper error handling is hard, nearly as much as 'naming things' :)

Re: Emulating exceptions in C: a case study

#24

Post by halayli » Thu, Aug 27, 2015, 6:08 PM UTC

rwmj wrote: post #21

halayli wrote: post #20

Exceptions are not about going from one place to another. It's about unwinding the stack properly and calling the destructors of variables on the stack. This is not a close emulation at all.

While I'm not saying this is a good idea, you can combine a pool allocator with longjmp exceptions to get an approximation of unwinding. It requires that you are very careful about structuring your code, but I once wrote a whole web server this way: http://git.annexia.org/?p=rws.git;a=tree (using: http://git.annexia.org/?p=c2lib.git;a=tree ).

But sometimes it's not just memory. It can be files you need to close, or any other resource held.

Re: Emulating exceptions in C: a case study

#25

Post by chaz72 » Thu, Aug 27, 2015, 8:40 PM UTC

halayli wrote: post #24

rwmj wrote: post #21

Earlier quoted context omitted.

While I'm not saying this is a good idea, you can combine a pool allocator with longjmp exceptions to get an approximation of unwinding. It requires that you are very careful about structuring your code, but I once wrote a whole web server this way: http://git.annexia.org/?p=rws.git;a=tree (using: http://git.annexia.org/?p=c2lib.git;a=tree ).

But sometimes it's not just memory. It can be files you need to close, or any other resource held.

That too can be queued up, with a list of functions to call to free those resources.

Re: Emulating exceptions in C: a case study

#26

Post by halayli » Fri, Aug 28, 2015, 1:32 AM UTC

chaz72 wrote: post #25

halayli wrote: post #24

Earlier quoted context omitted.

But sometimes it's not just memory. It can be files you need to close, or any other resource held.

That too can be queued up, with a list of functions to call to free those resources.

He was referring to a memory pool allocator. But regardless, good luck with the approach.

Re: Emulating exceptions in C: a case study

#27

Post by rwmj » Fri, Aug 28, 2015, 7:36 AM UTC

halayli wrote: post #24

rwmj wrote: post #21

Earlier quoted context omitted.

While I'm not saying this is a good idea, you can combine a pool allocator with longjmp exceptions to get an approximation of unwinding. It requires that you are very careful about structuring your code, but I once wrote a whole web server this way: http://git.annexia.org/?p=rws.git;a=tree (using: http://git.annexia.org/?p=c2lib.git;a=tree ).

But sometimes it's not just memory. It can be files you need to close, or any other resource held.

Pool allocators can easily deal with non-memory resources. The one I wrote in c2lib could.

Re: Emulating exceptions in C: a case study

#28

Post by Murk » Fri, Aug 28, 2015, 7:51 AM UTC

When I went for a job interview at Symbian many years ago for a position working on Symbian OS, they told me (and it's obvious from looking at their documentation) that they implemented thier own execption mechanism in C++ using setjmp and longjmp becuase they deemed that the C++ execption system was too slow. Other accounts say that the exception mechanism wasn't present in the language at the time, which I am not sure of.

This is why you had to push all local variables onto a clearnup list in each an every function, this I think, from memory was a call to CleanupStack::Push with a wrapper macro.

If indeed they did this becuase exxceptions were 'too slow', then the problem, im my option would be that they were using exceptions far too much -- as status indications and so on. They are, again, in my option a great help used in the right way, with the C++ RAII idiom, which is essential in the face of exceptions.