Is try - catch block advisable?
-
Eddy Vluggen wrote:
that's the place where one would log them.
But only at the top-most layer.
-
Forbiddenx wrote:
If Website, catch just about all exceptions and store them into a database fo
And what happens when the database throws an exception?
That hardly ever happens. :rolleyes:
-
I am going to compound a little on Eddy's Don't catch what you can't handle Don't throw what you can catch Expected exceptions are not exceptions test first, your code will be more rigorous.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost "All users always want Excel" --Ennis Lynch
Ennis Ray Lynch, Jr. wrote:
Don't throw what you can catch
Unless you are a value-added re-thrower.
-
Use try-catch unless you want your clients complaining "i got this error and then the entire application shut down".
Apps - Color Analyzer | Arctic | XKCD | Sound Meter | Speed Dial
I'd rather have them complain once and explain that it's a bug that will never resurface, than having a lot of exceptions (and invalid states) that I don't know of. I love the PHP-approach; either do or die, don't fake it.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
I'd rather have them complain once and explain that it's a bug that will never resurface, than having a lot of exceptions (and invalid states) that I don't know of. I love the PHP-approach; either do or die, don't fake it.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
I'm with Abhinav - use try catch, but report a problem to the user. Nothing, but nothing, is so damn annoying as losing an hour's work because a programmer didn't bother to allow for an alpha character in a numeric field! Have you never sworn because an app went "...caused an exception and needs to close" and you lose a bunch of work?
This message is manufactured from fully recyclable noughts and ones. To recycle this message, please separate into two tidy piles, and take them to your nearest local recycling centre. Please note that in some areas noughts are always replaced with zeros by law, and many facilities cannot recycle zeroes - in this case, please bury them in your back garden and water frequently.
-
Use try-catch unless you want your clients complaining "i got this error and then the entire application shut down".
Apps - Color Analyzer | Arctic | XKCD | Sound Meter | Speed Dial
Down vote countered - not checking or catching errors is just lazy programming, and is unfair on the people who pay our wages! :laugh:
This message is manufactured from fully recyclable noughts and ones. To recycle this message, please separate into two tidy piles, and take them to your nearest local recycling centre. Please note that in some areas noughts are always replaced with zeros by law, and many facilities cannot recycle zeroes - in this case, please bury them in your back garden and water frequently.
-
Down vote countered - not checking or catching errors is just lazy programming, and is unfair on the people who pay our wages! :laugh:
This message is manufactured from fully recyclable noughts and ones. To recycle this message, please separate into two tidy piles, and take them to your nearest local recycling centre. Please note that in some areas noughts are always replaced with zeros by law, and many facilities cannot recycle zeroes - in this case, please bury them in your back garden and water frequently.
OriginalGriff wrote:
Down vote countered
Thanks.
Apps - Color Analyzer | Arctic | XKCD | Sound Meter | Speed Dial
-
I'm with Abhinav - use try catch, but report a problem to the user. Nothing, but nothing, is so damn annoying as losing an hour's work because a programmer didn't bother to allow for an alpha character in a numeric field! Have you never sworn because an app went "...caused an exception and needs to close" and you lose a bunch of work?
This message is manufactured from fully recyclable noughts and ones. To recycle this message, please separate into two tidy piles, and take them to your nearest local recycling centre. Please note that in some areas noughts are always replaced with zeros by law, and many facilities cannot recycle zeroes - in this case, please bury them in your back garden and water frequently.
OriginalGriff wrote:
Nothing, but nothing, is so damn annoying as losing an hour's work because a programmer didn't bother to allow for an alpha character in a numeric field!
Yes, it's loosing a day because that exception is swallowed somewhere deeply within the system.
OriginalGriff wrote:
Have you never sworn because an app went "...caused an exception and needs to close" and you lose a bunch of work?
There's an auto-save, but my Ctrl-S reflex is still alive. And yes, I'd rather see my app die, than pretend nothing happened (and have it continue with corrupted data that gets saved later)
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
Down vote countered - not checking or catching errors is just lazy programming, and is unfair on the people who pay our wages! :laugh:
This message is manufactured from fully recyclable noughts and ones. To recycle this message, please separate into two tidy piles, and take them to your nearest local recycling centre. Please note that in some areas noughts are always replaced with zeros by law, and many facilities cannot recycle zeroes - in this case, please bury them in your back garden and water frequently.
OriginalGriff wrote:
not checking or catching errors is just lazy programming
No-one advocates "not" checking them; so the statement that one should is superfluous. Using a pokemon-handler is lazy; if you expect an exception, than you can see if you can handle it locally. Unhandled exceptions would be logged in a single place.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
OriginalGriff wrote:
Nothing, but nothing, is so damn annoying as losing an hour's work because a programmer didn't bother to allow for an alpha character in a numeric field!
Yes, it's loosing a day because that exception is swallowed somewhere deeply within the system.
OriginalGriff wrote:
Have you never sworn because an app went "...caused an exception and needs to close" and you lose a bunch of work?
There's an auto-save, but my Ctrl-S reflex is still alive. And yes, I'd rather see my app die, than pretend nothing happened (and have it continue with corrupted data that gets saved later)
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
I'm not saying "swallow it" and "pretend nothing happened". I'm saying use the tools and locate it while you (as a programmer) can still prevent it adversely affecting the user. Then report it, log it (both is good) and give them a chance to do something. Just letting your program crash is just being lazy! :laugh:
This message is manufactured from fully recyclable noughts and ones. To recycle this message, please separate into two tidy piles, and take them to your nearest local recycling centre. Please note that in some areas noughts are always replaced with zeros by law, and many facilities cannot recycle zeroes - in this case, please bury them in your back garden and water frequently.
-
OriginalGriff wrote:
not checking or catching errors is just lazy programming
No-one advocates "not" checking them; so the statement that one should is superfluous. Using a pokemon-handler is lazy; if you expect an exception, than you can see if you can handle it locally. Unhandled exceptions would be logged in a single place.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
Eddy Vluggen wrote:
No-one advocates "not" checking them;
Um.
Eddy Vluggen wrote:
And yes, I'd rather see my app die, than pretend nothing happened (and have it continue with corrupted data that gets saved later)
Eddy Vluggen wrote:
I'd rather have them complain once and explain that it's a bug that will never resurface, than having a lot of exceptions (and invalid states) that I don't know of. I love the PHP-approach; either do or die, don't fake it.
This message is manufactured from fully recyclable noughts and ones. To recycle this message, please separate into two tidy piles, and take them to your nearest local recycling centre. Please note that in some areas noughts are always replaced with zeros by law, and many facilities cannot recycle zeroes - in this case, please bury them in your back garden and water frequently.
-
I think we are misunderstanding each other. I do use specific exceptions but at times I also use the generic all exceptions.. But, I also bomb out if I use the generic all exception and stop everything in its tracks.
catch (Exception exc)
{
log it, or present it to the user exc...
BOMB OUT.... alert.. done.
I never resume operation that would be bad!
}I only resume operation if I
catch (ExceptionTYPE exc)
{
try to recover..
}Yes, it does add some extra code, but it is better then resuming you want to log any exception that occurs globally.
=)
Forbiddenx wrote:
But, I also bomb out if I use the generic all exception and stop everything in its tracks.
There's the problem; handling a "specific" exception means that you cannot use the generic exception to handle it - it'd be passing in other exceptions that weren't meant to be handled that way. Nice example is a Sql Server that's offline, and a client-app that keeps whining about a password being incorrect (since that was all that's handled locally). Hence, the best practice would be to catch and handle what you expect, and to log everything else on a higher level.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
Eddy Vluggen wrote:
No-one advocates "not" checking them;
Um.
Eddy Vluggen wrote:
And yes, I'd rather see my app die, than pretend nothing happened (and have it continue with corrupted data that gets saved later)
Eddy Vluggen wrote:
I'd rather have them complain once and explain that it's a bug that will never resurface, than having a lot of exceptions (and invalid states) that I don't know of. I love the PHP-approach; either do or die, don't fake it.
This message is manufactured from fully recyclable noughts and ones. To recycle this message, please separate into two tidy piles, and take them to your nearest local recycling centre. Please note that in some areas noughts are always replaced with zeros by law, and many facilities cannot recycle zeroes - in this case, please bury them in your back garden and water frequently.
OriginalGriff wrote:
And yes, I'd rather see my app die, than pretend nothing happened (and have it continue with corrupted data that gets saved later)
I do not advocate there that one should not handle exceptions. "Do or die" means that I'll try to close the app as gracefully as possible, with an apoligy to the user that an exception occured.
OriginalGriff wrote:
I'd rather have them complain once and explain that it's a bug that will never resurface
Does still not mean that I do not have a global exception handler; it's implemented, but it does not "hide" exceptions and pretend all is well. It get's logged, and once investigated, one can easily push an update that ignores that specific exception if that's safe. Imagine medical software being like that, and using the "default gender" if that information is lost after an exception on a conversion.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
I'm not saying "swallow it" and "pretend nothing happened". I'm saying use the tools and locate it while you (as a programmer) can still prevent it adversely affecting the user. Then report it, log it (both is good) and give them a chance to do something. Just letting your program crash is just being lazy! :laugh:
This message is manufactured from fully recyclable noughts and ones. To recycle this message, please separate into two tidy piles, and take them to your nearest local recycling centre. Please note that in some areas noughts are always replaced with zeros by law, and many facilities cannot recycle zeroes - in this case, please bury them in your back garden and water frequently.
-
I dont have a habit of using try-cahtch block unless i am sure it throws an exception... is it advisable to use it in most places of your code.... what is the best practice?
Srinivas K
Normally I don't us try-catch block. Except for exceptions I code myself and if there's something really not sure.
-
I dont have a habit of using try-cahtch block unless i am sure it throws an exception... is it advisable to use it in most places of your code.... what is the best practice?
Srinivas K
Try to avoid try-catch when you can. Often an if/else statement can help you out. (divide by zero, file exists, eof, ...) That doesn't mean you shouldn't use try/catch, but use them were appropriate. IOW some 'exceptional' thing might happen. (an object has a null value although it shouldn't, ... ) Hope this helps.
-
I'd rather have them complain once and explain that it's a bug that will never resurface, than having a lot of exceptions (and invalid states) that I don't know of. I love the PHP-approach; either do or die, don't fake it.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
Eddy Vluggen wrote:
than having a lot of exceptions (and invalid states) that I don't know of.
Been writing servers for 15 years, high capacity ones for 10, and I have never seen that. What I have seen are a lot of null pointer exceptions caused by programming adaptors in plugin architectures doing dynamic processing. Which means that the ALL transactions in flight would then fail simply because a one time data set caused a bug to show up. And I can note that in most cases the adapter code was not written by me but the plugin architecture was. I have seen catastrophic failures but they take the server down. And in that case catching the exceptions at least for the purpose of logging is critical.
Eddy Vluggen wrote:
I'd rather have them complain once and explain that it's a bug
I rather not have to explain anything when all the customers suffered some sort of failure due to something that could have been avoided.
-
OriginalGriff wrote:
And yes, I'd rather see my app die, than pretend nothing happened (and have it continue with corrupted data that gets saved later)
I do not advocate there that one should not handle exceptions. "Do or die" means that I'll try to close the app as gracefully as possible, with an apoligy to the user that an exception occured.
OriginalGriff wrote:
I'd rather have them complain once and explain that it's a bug that will never resurface
Does still not mean that I do not have a global exception handler; it's implemented, but it does not "hide" exceptions and pretend all is well. It get's logged, and once investigated, one can easily push an update that ignores that specific exception if that's safe. Imagine medical software being like that, and using the "default gender" if that information is lost after an exception on a conversion.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
Eddy Vluggen wrote:
Imagine medical software being like that, and using the "default gender" if that information is lost after an exception on a conversion.
Ridiculous analogy. Computers are deterministic even if it seems random at times. Catastrophic system failures in code that has even a reasonable amount of quality control are rare. Even rarer to happen in production. What happens much more are unexpected but normal errors. And at least in 24x7 servers (which you don't seem to be describing) it can't just quit because of an little known and non-tested data path results in a null pointer exception. When catastrophic errors do occur they are, oddly enough, catastrophic. They cause the entire system to fail and it is obvious. So you are hypothesizing some extremely rare circumstances where such an error allows the system to keep running yet corrupts the entire system completely such that there are no other validation checks that would catch anything (my code has validation checks.) And that just is not reasonable when compared to unexpected conditions which can be ignored and which occur much more often.
