Try/Catch should only exist in code calling out to an external service/library.Most of them are "if (x != null)" tests before it continues on. I feel like that's why you surround things in a try/catch.
I need a drink.Well the code itself already exists within a try/catch since it calls some IO methods. And again, even if you don't try to catch a Nullpointer by moving a check through an if statement, there should be an indication somewhere that, hey, the value was null so nothing was done. I've already run into more than one situation debugging the current production code where this coding predilection made it hard to track down a problem. Well, that and the near complete lack of comments.
Yes, this sounds like some hardcore high school programmingPost your code so that we maymock youhelp you improve.
They code what you ask for.I'm just griping. The code works, but it's sometimes difficult to follow. Didn't someone say a while back that Indian coders write shitty code? I have 10 apps worth of Indian coding.
I totally disagree with this.Try/Catch should only exist in code calling out to an external service/library.
Exceptions thrown in a layer should never be intended to be caught and handled in the same layer.
Otherwise you end up using Exceptions as GOTO statements.
I'm talking from a perfect world.I totally disagree with this.
Having a try/catch around code can be a hell of a lot cleaner than trying to make all your functions return true/false on whether they succeeded or not. With the exceptions you only handle failures, usually in a single line thrown exception vs handling return values then having more often than not repeated code to handle failures peppered throughout the code. A lot of the stupid nested if statements that people do are developers trying to handle failures/successes in the same code block.
In C++ it's way better to figure out what kind of errors you're going to handle and what kind of failures they mean (fatal,warning,log etc) and creating try/catches with exceptions types to handle these situations where they need to handled and doing it in a single spot. Throw a fatal error? It's handled at the top of your exceptions, a local error that triggers a log entry? That's handled locally where the error happened so the code can easily continue. It keeps the error handling well organized and you're handling all the same error types generally in the same way/location which is always a huge positive.
Sounds like Fox News or MSNBC has a job for you.Vinen_sl said:Try/Catch should only exist in code calling out to an external service/library.
Exceptions thrown in a layer should never be intended to be caught and handled in the same layer.
Otherwise you end up using Exceptions as GOTO statements.
Nested For Loops are a different story as each level of the loop can and should be written as separate methods in order to make it testable.
Then again, these are just in perfect world
Yeah I saw that the other day on programming or programmer humor. Got some laughs.
lol what? I edited out the pieces that weren't relevant to my rebuttal. You tossing "in a perfect world" doesn't suddenly make the content of your post good advice. The CPU cost of exceptions has to be weighed against what they give you in code complexity reduction and being able to unify your error handling. When used properly they are great tools, and shouldn't be avoided.I'm talking from a perfect world.
Exceptions are very expensive CPU wise. You expressly edited the quote
Sounds like Fox News or MSNBC has a job for you.
I don't like strong rules but generally I agree. Exceptions shouldn't be used to control program flow, they should be used to jump the control up some number of layers.Try/Catch should only exist in code calling out to an external service/library.
Exceptions thrown in a layer should never be intended to be caught and handled in the same layer.
Otherwise you end up using Exceptions as GOTO statements.
Nested For Loops are a different story as each level of the loop can and should be written as separate methods in order to make it testable.
Then again, these are just in perfect world
Bingo. This is the behavior I poorly described.In that topic, you can show a horse the water, but you cant force it to drink. My worker now is asking me about how to do exceptions with Web API, and HTTP return codes.
So I told him, only use exceptions for something catastrophic, and then return a 500 when that happens. Well that translated, to if the user send the incorrect parameters, that generates an exception =( .. instead of just returning a 400 right away.
Here is my ideal code snipet
His
Basically his is what you should not do.