So I've just learned that C has no exceptions

Instead, they use some weird setjmp/longjmp shit.
Holy fuck, and some trolls here dare say that "C is a good language".

Holy fuck, and some trolls here dare say that "exceptions are a good language feature".

>>2
They are infinitely better than what C has.

In using slj, one should bear in mind the following, assuming routine Parent() calls routine Setter(), which calls setjmp() and then calls Jumper, which in turn calls longjmp().

- Code may legally exit the scope in which a setjmp is performed without a longjmp having been executed; as soon as the scope exits, however, the previously-created jmp_buf must be regarded as invalid. The compiler probably won't do anything to mark it as such, but any attempt to use it may result in unpredictable behavior, likely including a jump to an arbitrary address.
- Any local variables in Jumper() will evaporate with the call to longjmp(), rendering their values irrelevant.
- Whenever control returns to Parent, via whatever means, Parent's local variables will be as they were when it called Setter, unless such variables had their addresses taken and were changed using such pointers; in any case, setjmp/longjmp will not affect their values in any way. If such variables do not have their addresses taken, it is possible that setjmp() may cache the values of such variables and longjmp() may restore them. In that scenario, however, there would be no way for the variables to change between when they are cached and when they are restored, so the cache/restore would have no visible effect.
- The variables in Setter may or may not be cached by setjmp() call. After a longjmp() call, such variables may have the value they had when setjmp() was performed, or the values they had when it called the routine which ultimately called longjmp(), or any combination thereof. In at least some C dialects, such variables may be declared "volatile" to prevent them from being cached.

C is shit, C is shit, C is a disgusting unusable pile of shit.

>>1
Nobody uses setjmp and no sane person uses exceptions. Use return values.

I am a Professional Apper and I use setjmp/longjmp regularly.

>>5
Nope. I wanted to use libpng and it uses setjmp.h heavily, that's how I learned about it in the first place.
And return values are no substitute because there are a million ways that a routine can crash before getting to the return statement.

>>7
Libpng is shit, there was even a thread about this.

And return values are no substitute because there are a million ways that a routine can crash before getting to the return statement.

Tell me then, does setjmp magically finds crashes and restores them? Or crashes happen randomly without reason? Bullshit

>>8
Things don't randomly crash if you have a decent cpu, not some trash like x86 that doesn't even have ECC in the ALU.

>>8
Was there a better alternative to libpng in that thread?

>>10
stdio.h has fgetc, which should be enough.

>>10
LodePNG and >>11

>>12
Fuck this is awesome. Thank you.

>>1
C programmers usually, pigheadedly, use goto - when procedures are an adequate abstraction for exception handling instead

>>12
LordePNG
self fix

>>7
dikita sadkov already made a thread like this. he also tried to make the exact same point: "C is shit because libpng is shit"

>>14

procedures are an adequate abstraction for exception handling

Adequate, yes. Ideal, no.

In the general case, handling error conditions requiring early termination of a procedure in C involves either deeply nesting conditionals, returning early, or using goto. Many compilers generate bad code for early returns, so if you are really concerned about performance and want to avoid nesting you are suck with goto.

>>17
there are more important metrics than speed ya farking speedy gonzalis kunt

>>18
Not when you program in C. If speed isn't your #1 priority, you can write in anything but C.

Nesting is awesome, I always use nesting and try to avoid using more than one return per function.

>>19
Use assembly like Cudder then.

>>20
C is much more portable with almost the same efficiency.

>>18

there are more important metrics than speed

Oh, I agree. You also have to consider code size and readability. Unfortunately there are many cases where a forward goto that jumps into the epilogue of a long function wins on size (vs. using a separate function for cleanup) and readability (vs. nesting conditionals).

Don't misunderstand me, I would certainly like to have a more structured way of doing error handling with minimal overhead. Until the language provides one, though, you'll have to excuse me for using goto where there is no superior alternative.

>>22
There are cases where goto is a better option but this ain't one. Nesting conditionals are very damn readable.

>>23
I would argue that conditionals that nest more than 3 or 4 levels deep are not very readable, especially when the nesting is done entirely to accommodate error cases that must break out of the whole structure anyway. Writing code that way also complicates maintenance because the error path becomes an implicit property of the conditional structure. The first time someone else needs to add a new branch the whole thing will come tumbling down.

come tumbling down my anus

>>24
Exceptions