Why not: // just shoot me!
-
try { account.Save(); } catch { ; } //Not good! :mad:Guess programmer was hungry thats why he "ate" the exception :D
Always Keep Smiling. Yours Pankaj Nikam
-
try { account.Save(); } catch { ; } //Not good! :mad:Relax. This is just sweeping under the rug. It could be worse.
Mislim, dakle jeo sam.
-
try { account.Save(); } catch { ; } //Not good! :mad:I'm impressed they wasted the energy on a surplus semicolon.
Software Zen:
delete this; -
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; -
I'm impressed they wasted the energy on a surplus semicolon.
Software Zen:
delete this;:-D What kills me is the comment. It would have taken the same effort to say Logger.Log(ex);
-
try { account.Save(); } catch { ; } //Not good! :mad: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.
-
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.
-
try { account.Save(); } catch { ; } //Not good! :mad: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.
-
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.
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.
-
try { account.Save(); } catch { ; } //Not good! :mad:Well if saving doesn't work now, it could work later... ;P
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
-
try { account.Save(); } catch { ; } //Not good! :mad: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; }
-
Well if saving doesn't work now, it could work later... ;P
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
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...
-
try { account.Save(); } catch { ; } //Not good! :mad:I've read somewhere that this code is equivalent to:
try
{
// account.Save(); // If this can fail silently, then why bother?
}
catch { ; } //Not good!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've read somewhere that this code is equivalent to:
try
{
// account.Save(); // If this can fail silently, then why bother?
}
catch { ; } //Not good!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).
A fantastic point.
-
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. :rolleyes:
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.
-
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.
-
try { account.Save(); } catch { ; } //Not good! :mad:I will not shoot you, but support team will do, after over 9000 calls from angry users...
-
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 :laugh:
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.