|
Relax.
This is just sweeping under the rug.
It could be worse.
Mislim, dakle jeo sam.
|
|
|
|
|
I'm impressed they wasted the energy on a surplus semicolon.
Software Zen: delete this;
|
|
|
|
|
They might have a style rule that enforces:
"catch block cannot be empty"
Warning: Empty catch block.
ftfy: ";"
|
|
|
|
|
... which just demonstrates how misleading style enforcement can be.
Software Zen: delete this;
|
|
|
|
|
 What kills me is the comment. It would have taken the same effort to say Logger.Log(ex);
|
|
|
|
|
I'm trying (in vain so far) to think up any scenario where the context around this might make this o.k. For example, something like:
int pageIndex = 0;
try {
pageIndex = int.TryParse(Request[pageNum])
} catch (Exception e) {
Logger.info("Page Index of " + Request[pageNum] + " invalid, using " + pageIndex.ToString());
}
(Of course, I'd use Int.TryParse instead and null-check the request variable)
But, you get the idea--some scenario where you can continue to operate with default data given an unexpected condition. I can't think of any situation where the missing context makes it o.k. to swallow an exception trying whatever a Save operation does.
|
|
|
|
|
In this case it's just plain sloppy, lazy, and wrong. It should log and throw, allowing the error to propagate to the global error handler. The object's been validated so if the save fails it's a critical failure somewhere in the system, like the database is down. Eating the error when a save fails is never the right thing to do. The user blissfully goes about their business because the save "worked" but it didn't. Wrong, wrong, wrong.
|
|
|
|
|
I can think of situations where it might be appropriate to do something like that.
For instance, suppose you are implementing a "like" button or something similar. It's not critical that it works and let's assume that it's unreliable for reasons beyond the programmer's control, like maybe it depends on an external service which is not always available.
So in that case maybe it's OK to swallow the exception since it's not unusual and nothing will really break if it fails, so you just silently fail and the user can try again if they want. There aren't many situations like this in programming though, and you still should probably log the exceptions.
I'm pretty sure that something like account.Save() is a bit too important to treat this way, though.
|
|
|
|
|
StatementTerminator wrote: implementing a "like" button or something similar. It's not critical that it works
Man, people split up because of a 'like' button. You don't 'like' in time -- you loose. It IS crtical. 
Greetings - Jacek
|
|
|
|
|
That's OK, people who care about "like" buttons should be ostracized anyway.
On a side note, if I hear someone at my organization say one more time that our site needs to be more like Facebook, I'm going to garrote myself with a Cat5 cable.
|
|
|
|
|
Well, CP seems to go in that direction, too... It is a matter of time when it becomes "CodeBook". If it makes you feel better, I can vote you down 
Greetings - Jacek
|
|
|
|
|
This is why I hate the facebook, I cannot hate things, can only like things. How in the world I am supposed to only like things.
|
|
|
|
|
Luiz Felipe Stangarlin wrote: This is why I hate the facebook, I cannot hate things, can only like things. <layer>How in the world I am supposed to only like things.
I think exactly opposite. While I'm not a huge fan of a facebook, this particular feature is fine for me. Whereas I do dislike various things, a non-existance of downvoting mechanism forces me to express the dislike in a commentary (hopefully constructive). No downvoting makes the website more positive, which is a desired feature for a social network. We all have enough univoters in the real life...
Anyway, there are a lot of "hatred groups" on FB. Giving a 'like' to them is a way to express hatred, if you really need to.
Greetings - Jacek
|
|
|
|
|
Looks to me like the original programmer was too lazy to handle an exception, and another programmer came along and added the helpful "Not good!" comment, and left it like that. I don't know which programmer to hate more.
Five bucks says that account.Save() has a return value indicating success.
|
|
|
|
|
Well if saving doesn't work now, it could work later... 
|
|
|
|
|
RafagaX wrote: Well if saving doesn't work now, it could work later...
Oh, yea! Really user friendly. I ask to save, it works fine. Except I don't know if it worked or not. So now I've got to retrieve the data. If it is retrieved, fine, it worked. If not, then I get to save again and then check again and...
|
|
|
|
|
If in the account class the Save method looked like this there might be a scenario where the eating of exceptions is fine:
try
{
// Some code to save the record to the db
....
}
catch(Exception ex)
{
logger.Log(ex);
throw;
}
|
|
|
|
|
I've read somewhere that this code is equivalent to:
try
{
}
catch { ; }
Then again, a LART would be more educational. 
Pablo.
"Accident: An inevitable occurrence due to the action of immutable natural laws." (Ambrose Bierce, circa 1899).
|
|
|
|
|
|
I will not shoot you, but support team will do, after over 9000 calls from angry users...
|
|
|
|
|
I notice that a fair few of the recent posts here seem out of place.
Can't people read?
ps. I guess that by posting this, I now have to include myself in that category, but I'm hoping to be indulged.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Two wrongs don't make a right. 
|
|
|
|
|
But three lefts do.
(well, someone had to do it!)
Quidquid latine dictum sit, altum viditur.
|
|
|
|
|
I resisted doing it myself.
|
|
|
|
|
And remember that there will always be a future in computer maintenance...
Assuming you were quoting the Deteriorata.
Psychosis at 10
Film at 11
Those who do not remember the past, are doomed to repeat it.
Those who do not remember the past, cannot build upon it.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
