[structAnkit]

I do sort of agree with the try/catch criticism. I know what it achieves and why we need it but I don't agree that it's the best or even most intuitive error handling mechanism. I personally prefer returning error messages in place of or alongside expected data structure outputs, such as the common paradigm in JavaScript where async functions return error info (or null) as the first parameter in the supplied callback before returning the actual data (if no error) in the subsequent parameters.

I do somewhat agree with the OOP criticism as well. I find the best programming achievable is by mixing strategies and not adhering strictly to any one philosophy. Java's OOP is so inflexible and limiting that it takes a significant amount more effort to get basic work done. It may lead to a somewhat more manageable codebase at first, but I feel experience in your language of choice can bridge the gap between such a strict static-typed language vs a more elegant but potentially messier dynamic-typed language in this respect.

Finally I do agree that C should be taught before you learn any other programming language...but not to such a degree that you need to be able to build the best Javascript engine in the world from scratch before you move onto another programming language. The goal of programming is to build software that saves you time, after all - you aren't saving much time with as high a barrier to entry as mastering the fundamentals of C. It is important for theory discussion as well as learning the best way to code a lot of logic in many other languages, but I feel an abstracted language has failed if it hasn't done enough of the work for you to refactor your code properly in the first place. Loop unrolling, seriously? I like that I learned why it's important...but I shouldn't ever have to do that in any decently programmed higher level language.

[Quarrelsome]

I don't. Exceptions in general FORCE a developer to deal with the problem. They can slap a developer in the face if they're abusing the API.

Error codes on the other hand can be ignored.

PutLionInCage();

PokeLionWithStick();

I'd rather PutLionInCage() throws if there is a problem.

[suresk]

They don't necessarily force the developer to deal with the problem, unless you're talking about checked exceptions (which are a whole other controversial programming opinion). What they do accomplish, in my opinion, is more deterministic behavior and easier debugging.

If you rely solely on return codes to indicate an invalid state and the caller is free to ignore the error codes, it makes it much easier for the program to continue on doing invalid things - this is akin to wrapping everything with try/catch blocks and suppressing exceptions. Even more, when you do realize something is wrong, a system utilizing exceptions is generally much better at propagating information about the original problem.

[Silhouette]

Exceptions in general FORCE a developer to deal with the problem.

There are good arguments in favour of exceptions, but I don't think this is one of them. If Java has taught us anything, it is that trying to force someone to handle exceptions just causes a lot of code that says:

    catch (Exception e)
    {
        // silently ignore e
    }

[suresk]

Actually, the correct comment for an empty catch block is:

// This should never happen.

(Until it does)

I have mixed feelings about checked exceptions. They seem like a great idea in theory - if there are known error states, then making them explicitly known and forcing the consumer to acknowledge them in some way seems reasonable. In practice, a lot of the time the only response to a checked exception is "let it propagate up - there isn't anything useful I can do", which leads to extra code and can be annoying.

Even though I don't have quite the negative feelings toward them others do, if I were involved in designing a new language today, I'd probably vote against including them. It would possibly be nice if a method could explicitly declare which exceptions it was likely to throw, and then an IDE or static analysis tool could use those to aid consumers of the API, without forcing them to deal with every single one.

Interestingly enough, I view Scala's Option construct as being somewhat similar - forcing the consumer to acknowledge that a particular call could return a null value - but it doesn't seem to provoke the same negative visceral reactions that checked exceptions do.

[Quarrelsome]

Sure you can do that but the programmer is FORCED to make the choice to write that. Also the code _looks_ wrong like that.

Furthermore if the dev just wraps the entire process in that silent catch then the lion doesn't get poked!

[hackinthebochs]

If you need an exception here, you're just a bad programmer. It's your fault you didn't explicitly check that the lock was functional before poking that lion! /s

[Quarrelsome]

Sure but are you telling me you always work on teams where everyone is shit hot?

If you write a library are you thinking that everyone is going to use it properly?

My point is that exceptions help people to learn how to use APIs (its kinda like documentation that appears through use!) and exceptions make things _safer_.

I appreciate you could write the above in two try catches but my point is that it would look more wrong. The code above _looks_ fine and that's my point.

[hackinthebochs]

Hah, I guess my post could have used a sarcasm tag :)

I totally agree that exceptions are far superior than checking return values.

[xionon]

But sometimes it's not just the programmer that gets bitten, it's all the other people at the zoo, too. Exceptions help protect everyone.