Anyone else hates this kind of statements:

if ( doSomething() != SUCCESS ) {
//log error
}else {
//continue doing other stuff
}

I simply find that confusing. This is much better:

If ( doSomething == SUCCESS ){
//continue doing other stuff
}else {
//log error
}

Maybe just my opinion.

That depends really, if your "doing stuff" takes many LOC then else with logging error can visually detach from if by simply being off screen for example, which would make things less readable.
Otherwise sure, i agree that == SUCESS is better than !=

Would you not rather use exceptions to signify something went wrong?

I hate else statements. Exit early, exit often. If exception occurs, throw it.

Avoid else, try to make function so that it exits in error checking if. Exceptions are not worth it... I have yet to see a convincing case for exceptions.

@meros Unified exception handler(s) instead of having that logic cluttered all over the place.

The problem is that when used, exceptions are rarely exceptional. Normal errors are better communicated through normal program flow imo. The other problem is that it's so easy to ignore catching exceptions. I feel the c-style or even go-style way of doing it is better in the long run. I can accept exceptions for out of memory or similar really exceptional situations...

@meros Well, it depends on what one defines as being an exception. To me, it not how often they occur but why. They mark either an unexptected or an erroneous state. Runtime exceptions for example are quite normal and often occuring, e.g. faulty user input, logic exceptions should only happen during development and lead to an immediate bugfix, e.g. a faulty type passed to a method. So while there are severity layers to exceptions, it's not that they have to occur rarely. Yet I have seen enough code that avoids using exception, which brings you the pain of then having to handle "null" returns or magic numbers, which may be "0" or "-1". And worse: The amount of side effects grows and grows. It's a mess.

Just throw a proper Exception. Handle it or let the application crash. To me, it's better than the alternative.

@k0pernikus Unfortunately I am working with a legacy application right now and they don't use exceptions to follow the conventions. All the new applications uses exception which is just a better way of handling things

I am not a fan of C in general, but there is beauty in the simplicity of the error handling. Errors are part of the contract or signature of a function, and I strongly feel that exceptions do little except hide that fact. I don't like the custom enums commonly used for errors I C however. The go model where you commonly return result and/or error (supporting multiple return calues) is pretty clean though.

if (do_something() < 0) {
perror("do_something");
return -1;
}

// do the rest, with one lesser level of indentation! \o/

I mean, if you check for SUCCESS and need to do that for three return values in a row, that 80 col limit will get uncomfortable real quick.

I think there are two ways: optimist and pessimist.

Exceptional discussion...

@meros thanks for pointing me to the go way, it seems to be an interesting and pragmatic approach; I am wondering how that feels in the wild. And it adds yet another reason to learn go ;)

@Gauthier There's a particular reason that won't work in that case.

@tahnik What, you need deallocation on error?