|
Well, that does explain it. Design by upper management strikes again!  
Just because the code works, it doesn't mean that it is good code.
|
|
|
|
|
LOL
it made me laugh enough.
|
|
|
|
|
Everything about this method (PHP) is just wrong... it also throws a fatal error because it's setting $res to a string, and then calls getNext() on it the next iteration. Wtf...
static function searchCausalLink( $pageName, $rev ) {
if ( $rev == 0 ) {
return 'none';
} else {
$res = utils::getSemanticQuery( '[[Patch:+]][[onPage::' . $pageName . ']][[Rev::' . $rev . ']]', '?PatchID' );
if ( $res === false ) return 'none';
$count1 = $res->getCount();
for ( $j = 0; $j < $count1; $j++ ) {
$row1 = $res->getNext();
if ( $row1 === false )
break;
$row1 = $row1[0];
$col1 = $row1->getContent();
foreach ( $col1 as $object1 ) {
$wikiValue1 = $object1->getWikiValue();
$res = $wikiValue1;
}
}
return $res;
}
}
|
|
|
|
|
Academic people apparently don't know about it. This is the second time I find something like this in code written by academics 
public function getText() {
$textImage = "";
$tmp = $this->lineList;
$nb = 0;
$nb = sizeof( $tmp );
for ( $i = 1; $i <= $nb; $i++ ) {
if ( $i == 1 ) $textImage = $tmp[$i];
else $textImage = $textImage . "\n" . $tmp[$i];
}
return $textImage;
}
|
|
|
|
|
An inexperienced developer I use to work with kept telling me that she, "..wanted to add exception handling.." to her code. For various reasons, I wasn't quite sure what she meant by that and for other reasons, I didn't bother asking...
A couple weeks later, I did a diff on one of her check-ins to find that she had gone into a particular class (C#) and added try/catch blocks to every function in the class that looked like this:
public void FunctionName()
{
try
{
}
catch (Exception e)
{
throw e
}
}
|
|
|
|
|
Meh, catching and re-throwing exceptions does have its uses, just not with throw e.
Say if you want to log the exception and don't trust that whoever wrote the calling function will do it, you could write;
try
{
}
catch(Exception ex)
{
throw;
}
Or if you catch multiple exceptions and want to re-throw those you don't want to handle like;
try
{
}
catch(SQLException sqlex)
{
}
catch
{
throw;
}
What this actually is, is a chance for you to mentor an inexperienced developer on the correct way to use try/catch blocks.
People are more violently opposed to fur than leather because it's safer to harass rich women than motorcycle gangs
|
|
|
|
|
Rod Kemp wrote: What this actually is, is a chance for you to mentor an inexperienced developer on the correct way to use try/catch blocks.
...and a code horror.
|
|
|
|
|
aspdotnetdev wrote: and a code horror
Personally I would only view this as a true horror if it was done by an experienced developer who should know better, such as that use of Goto that DD shared the other day.
This is a rookie developer that according to the OP kept telling me that she, "..wanted to add exception handling.." to her code which would suggest she didn't know where to start and didn't get any help/tips/pointers on how to go about it.
I think a good way to judge if something is a coding horror is the 2x4 test. If you take into account the experience of the developer and look at the code and think that maybe you should explain how something works, then it's not a horror as such, if however your first thought is, where is that 2x4 so you can beat them over the head with it, then it is a horror.
People are more violently opposed to fur than leather because it's safer to harass rich women than motorcycle gangs
|
|
|
|
|
|
Clearly there are uses for catching an exception of a particular type or of any type, doing some processing and then re-throwing the exception. However, that was not the case here. She just re-threw it. I recognize that it is technically harmless but this individual was supposedly weeks away from graduating with a CS degree - at that point you should understand exceptions, scope and all sorts of fundamentals that this kind of coding shows she does not.
|
|
|
|
|
|
doja93 wrote: I recognize that it is technically harmless
Not really... rethrowing the exception with throw e; breaks the stack and you never get to see where the original exception was thrown.
That said, I'm with what the others said earlier in the thread: It's a good opportunity to mentor someone before they get ruined by some jackaninny who doesn't understand proper exception handling.
=============================
I'm a developer, he's a developer, she's a developer, Wouldn't ya like to be a developer too?
|
|
|
|
|
I'd also like to point out that of all the post I read in this thread, the parent to this post is the only one that was actually rethrowing the exception. Everyone else was repackaging the exception then throwing the repackaged exception which usually has the unintended consequence of losing the stack on the throw. Using the method the parent used ("throw" without a exception type reference) rethrows the last exception, full stack spool and all.
i.e.
Good:
try
{
}
catch(Exception ex)
{
throw;
}
Bad:
try
{
}
catch(Exception ex)
{
throw ex;
}
|
|
|
|
|
HI,
I do not really understant why we have to catch the exception and throw it.
I mean if a (first)function/sub is caling another (Second)function/sub if any exception is coming in sencond function why we have to catch it and throw it. It will automatically throw the exception right?
function1()
{
try
{
calling function2()
}
catch(exception e)
{
}
}
function2()
{
}
modified on Monday, November 29, 2010 7:18 AM
|
|
|
|
|
mohan5k wrote: I do not really understand why we have to catch the exception and throw it.
For your own code where you write the functions and you call them and you know you will catch and handle any exceptions it is not required that in your example function2 has a try/catch that re-throws the exception.
Where it does come in handy is when you are writing code that other people will use, in this case you may want to log all errors do you trust that the people using your code will do this for you or do it correctly, no you don't, you catch all errors log them then re-throw them back to the calling code or you may only want to re-throw errors under specific conditions such as if you are catching the SQLExceptions and get SQL Error 1205 (deadlock) you may want to retry the operation where as all other errors you may throw back to the calling code.
How you use it depends on what you are doing and how you expect it to be handled.
People are more violently opposed to fur than leather because it's safer to harass rich women than motorcycle gangs
|
|
|
|
|
I know what you are tyring to say..
I just commented for the above post as they simply catching and throwing it again with out doing any work..
|
|
|
|
|
|
To your second example, the easier solution would be not to have a "general" catch block at all, right?
try
{
}
catch(SQLException sqlex)
{
}
On the other hand, the opposite really does require a rethrow:
try
{
}
catch(SQLException sqlex)
{
throw;
}
catch
{
}
|
|
|
|
|
You could leave out the general catch but personally I prefer to have it there as I think it leads to the readability of the code, also I generally don't have a general catch that re-throws the exception without logging the exception in some manner such as the first example I showed.
People are more violently opposed to fur than leather because it's safer to harass rich women than motorcycle gangs
|
|
|
|
|
You can also use re-throwing an exception to add more information e.g.
public void SomeFunction()
{
try
{
// Do stuff
}
catch (Exception e)
{
// Do logging
throw new Exception("Some additional informative text.", e);
}
}
I've used this technique before, you just need to remember to walk the nested exceptions (InnerException) when you finally process the Exception.
Kevin Rucker, Application Programmer
QSS Group, Inc.
United States Coast Guard OSC
Kevin.D.Rucker@uscg.mil
"Programming is an art form that fights back." -- Chad Hower
|
|
|
|
|
Rod Kemp wrote: try {
// code that may throw exception here
}
catch(SQLException sqlex)
{
//Handle this exception here
//Don't re-throw the exception
}
catch {
throw; //re-throw all other exceptions that may occur
}
You really should not have put in the generic catch in this case. While cycles are cheap, this throws many cycles away for no reason. Simply catch those you are interested in and let the others roll up. No need to catch them if you plan to do nothing but throw them.
|
|
|
|
|
I never said this was production code but rather a way to teach an inexperienced developer about exception handling which should go beyond try/catch blocks and also incorporate defensive programming, maybe you should read the rest of my comments.
That said, during normal operation having the general catch block has no impact on performance it is only when something goes wrong that it may take a few cycles to propagate the error, but honestly if you're bothering to optimise your code at that point you really need to get out more.
People are more violently opposed to fur than leather because it's safer to harass rich women than motorcycle gangs
|
|
|
|
|
If he doesn't even know what she meant by 'add exception handling' - how much do you think he is going to be able to tutor her
Life goes very fast. Tomorrow, today is already yesterday.
|
|
|
|
|
It does actually get worse. I've seen
public int FormatSomethingOrRather(string txt)
{
try
{
}
catch (Exception)
{
}
}
That took about a day to track down the bug it was causing. So after fixing I ran FxCop and found dozens 
|
|
|
|
|
Obviously the exception should be handled recursively, so that when it's thrown, it's caught again. But if it's an inexperienced developer, I can understand this mistake.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
