IT/Software career thread: Invert binary trees for dollars.
- Thread starter Traak
- Start date
Vinen
God is dead
- 2,783
- 490
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
moontayle
Golden Squire
- 4,302
- 165
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.
Noodleface
A Mod Real Quick
- 37,961
- 14,509
Sometimes I have to write really dirty nested if-else statements and I just feel like a shitlord.
Vinen
God is dead
- 2,783
- 490
I need a drink.
Yes, this sounds like some hardcore high school programming
Vinen
God is dead
- 2,783
- 490
We have a middleware guy who is like working with an overseas contractor. If you ask him exactly the right question he will give you the answer. But he implies absolutely nothing or forms any meaning from your emails. So to get anything done takes like at least 5 emails of back and forth until you get the full picture.
Tripamang
Naxxramas 1.0 Raider
- 5,233
- 31,877
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.
Vinen
God is dead
- 2,783
- 490
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.Vinen_sl said:
Noodleface
A Mod Real Quick
- 37,961
- 14,509
Yeah I saw that the other day on programming or programmer humor. Got some laughs.
Tripamang
Naxxramas 1.0 Raider
- 5,233
- 31,877
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.
Tuco
I got Tuco'd!
- 45,604
- 73,737
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
Some people overuse/abuse exceptions and it can end poorly. When I find a library written by someone who really likes exceptions it seems like it's just a matter of time until they mis-use it.
I had to fix a bug today in production level code for a system we purchased where the method for the exception object threw an exception. As in
This meant that if you tried to determine what the exception was when it was thrown you might get another exception out of the thing.
Vinen
God is dead
- 2,783
- 490
Lendarios
Trump's Staff
- 19,360
- -17,424
In that topic, you can show a horse the water, but you cant force it to drink. My co-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.
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.
Vinen
God is dead
- 2,783
- 490