 |
|
Another two (three?) hours spent on this kind of typo:
public int LoadedSampleCount
{
get { return (int)GetValue(LoadedSampleCountProperty); }
set { SetValue(LoadedSampleCountProperty, value); }
}
public static readonly DependencyProperty LoadedSampleCountProperty =
DependencyProperty.Register("LoadedSampleCount", typeof(int), typeof(TreeWindowVM SampleSetLoaderVM), new PropertyMetadata(0));
This is a result of a "GUI refactoring" -- moving parts of code to an user control. And forgetting to set an owner of a dependency property to a new model view again. Awww... 
Greetings - Jacek
|
|
|
|
|
Just came across the following in some code I maintain:
foreach (Object item in group)
{
int i = 1;
string key = "SomeString_" + i.ToString();
}
I suspect the idea was to use i to help make the dictionary keys unique.
|
|
|
|
|
try
{
account.Save();
}
catch { ; }
|
|
|
|
|
At least there are comments.
|
|
|
|
|
I can think of a few comments myself...
The universe is composed of electrons, neutrons, protons and......morons. (ThePhantomUpvoter)
|
|
|
|
|
Guess programmer was hungry thats why he "ate" the exception 
Always Keep Smiling.
Yours Pankaj Nikam
|
|
|
|
|
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
|
|
|
|
|
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 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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Rant 
Admin 
Submit an article or tip
Post your Blog
