try-catch code convention [modified]
-
dont know, but I had to laugh so hard when he told me this... everybody who knows the disciplines of "Software Engineering" must either laugh or puke
It's from BP's oil valve device driver source code..
-
It's from BP's oil valve device driver source code..
-
Haha, funny. Sadly enough, I used to swallow exceptions in code as well. However, I'm not in the professional field, just personal. It worries me that this sort of thing is done by professionally employed developers. xD
Squelching exceptions can be a legitimate tactic. For example, suppose you're writing an error handling routine. The routine probably tries to do many things related to error handling: write out a log file, send an e-mail, etc. If any of these fails, you won't want this second failure to disrupt the rest of the error routine, nor will you want it to throw a new exception (which would quite likely propagate out to the OS level, and result in a GPF). Another legitimate reason to squelch is the existence of OS level bugs and failures that are outside the developer's control. There was a bug in Windows a few years that caused "insufficient memory" errors whenever the system entered "sleep" mode due to inactivity. I cannot really detect that as a .NET developer, except in the form of an "out of memory" exception. And the error condition is bogus, or at least temporary; so I do not want my program to GPF, I really do want it to ignore the exception and continue trying to operate. Squelching this error is legitimate, I think. I have had architect types tell me that exceptions should never be squelched. That simply doesn't square with reality for me, though. A better policy, I think, is to have guidelines for squelching exceptions, e.g. squelch only the most specific exception type possible, always put an explanatory comment in the "catch" block, don't use this tactic for simple validation of inputs, etc.
modified on Saturday, July 3, 2010 12:33 PM
-
a fellow student told me of a strange code convention in his job: almost every single method looks like this
//method head
{
try {
//actual method body
}
catch (...) {
}
}directly after the head opens a
tryblock over the whole body. all errors are just thrown away. the programs work and never crash! they are world market leader :-D seems this fast and easy developing is quite successfull at all. they are more engineers, so these kludges seem appropriate.modified on Thursday, July 1, 2010 2:57 PM
Apparently you are not a man of faith, and do not realize that this is a Marine software design tactic. Swallow 'em all and let God sort 'em out!
<Pretentious> Raid tha manyuhl. :E <Pretentious> Aw raid eh own mah meaxbile. :E
-
Discarding errors is a great way to give the user the perception that all is right with the world.
RugbyLeague wrote:
a great way to give the user the perception that all is right with the world.
That's the goal, according to some of the teachers here. If you find yourself in such a group, by all means, adapt or leave - you'll be the source of all bugs and errors if you try to move to structured error-handling :)
I are Troll :suss:
-
a fellow student told me of a strange code convention in his job: almost every single method looks like this
//method head
{
try {
//actual method body
}
catch (...) {
}
}directly after the head opens a
tryblock over the whole body. all errors are just thrown away. the programs work and never crash! they are world market leader :-D seems this fast and easy developing is quite successfull at all. they are more engineers, so these kludges seem appropriate.modified on Thursday, July 1, 2010 2:57 PM
I'm guessing that the convention dates from the VB style, used to use this:
Function Wibble() As String
Dim sResult As StringOn Local Error GoTo Fail
'stuff goes heredone:
Wibble = sResult
Exit FunctionFail:
LogError "Wibble", Err
Resume done
End Function
Panic, Chaos, Destruction. My work here is done. or "Drink. Get drunk. Fall over." - P O'H
-
I'm guessing that the convention dates from the VB style, used to use this:
Function Wibble() As String
Dim sResult As StringOn Local Error GoTo Fail
'stuff goes heredone:
Wibble = sResult
Exit FunctionFail:
LogError "Wibble", Err
Resume done
End Function
Panic, Chaos, Destruction. My work here is done. or "Drink. Get drunk. Fall over." - P O'H
well, the difference is, that your code logs the error. in try/swallow it just thrown away. logging all the error messages might bloat the logfile ;)
-
a fellow student told me of a strange code convention in his job: almost every single method looks like this
//method head
{
try {
//actual method body
}
catch (...) {
}
}directly after the head opens a
tryblock over the whole body. all errors are just thrown away. the programs work and never crash! they are world market leader :-D seems this fast and easy developing is quite successfull at all. they are more engineers, so these kludges seem appropriate.modified on Thursday, July 1, 2010 2:57 PM
If you have common functions reachable by the GUI, that are not important for the main of the application, this is a really usefull and stable act, and i do it in almost the same manner for at least the common methods. For example i wan't to change a image of a specified object. Now my ChangeImage() method throws a unhandled exception, with this try catch block around the method body there will be no quaint exception message, the application won't crash because of a single method exception, only the ChangeImage() method isn't working. ;) Sorry for my bad english.
-
Squelching exceptions can be a legitimate tactic. For example, suppose you're writing an error handling routine. The routine probably tries to do many things related to error handling: write out a log file, send an e-mail, etc. If any of these fails, you won't want this second failure to disrupt the rest of the error routine, nor will you want it to throw a new exception (which would quite likely propagate out to the OS level, and result in a GPF). Another legitimate reason to squelch is the existence of OS level bugs and failures that are outside the developer's control. There was a bug in Windows a few years that caused "insufficient memory" errors whenever the system entered "sleep" mode due to inactivity. I cannot really detect that as a .NET developer, except in the form of an "out of memory" exception. And the error condition is bogus, or at least temporary; so I do not want my program to GPF, I really do want it to ignore the exception and continue trying to operate. Squelching this error is legitimate, I think. I have had architect types tell me that exceptions should never be squelched. That simply doesn't square with reality for me, though. A better policy, I think, is to have guidelines for squelching exceptions, e.g. squelch only the most specific exception type possible, always put an explanatory comment in the "catch" block, don't use this tactic for simple validation of inputs, etc.
modified on Saturday, July 3, 2010 12:33 PM
-
I think the point was that it was in EVERY method ...
Jammer My Blog | Articles | DMon | SampleSort
Originally I think that was the point. The post I actually responded to seemed to impugn any and all squelching of exceptions ("[s]adly enough, I used to swallow exceptions in code as well..."). This blanket statement is actually one I hear a lot, even from people pretty well-placed in software development.
-
Kevin Drzycimski wrote:
directly after the head opens a try block over the whole body. all errors are just thrown away.
In Enterprise lingo, that's called the Try/Swallow pattern.
Jon Sagara Some see the glass as half-empty, some see the glass as half-full. I see the glass as too big. -- George Carlin .NET Blog | Personal Blog | Articles
Jon Sagara wrote:
Try/Swallow
I'm scared to reply to that one!
Dave
If this helped, please vote & accept answer!
Binging is like googling, it just feels dirtier. Please take your VB.NET out of our nice case sensitive forum.(Pete O'Hanlon)
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn) -
If you have common functions reachable by the GUI, that are not important for the main of the application, this is a really usefull and stable act, and i do it in almost the same manner for at least the common methods. For example i wan't to change a image of a specified object. Now my ChangeImage() method throws a unhandled exception, with this try catch block around the method body there will be no quaint exception message, the application won't crash because of a single method exception, only the ChangeImage() method isn't working. ;) Sorry for my bad english.
I think it's true that failures related to some less significant features should not be allowed to disrupt other features. Even logging these failures in a production environment can impact other critical systems. So, there are probably legitimate cases where errors related to an entire subsystem should be squelched in the production build. Doing this is, at some level, a revival of
ON ERROR RESUME NEXT. At a minimum, I think that good programming practices dictate that unhandled exceptions should halt the program in its development builds (even if some of these are squelched in the "release" build). So long as the transition between build modes is automatic and reliable, this can be a good approach to exception handling for some applications. -
a fellow student told me of a strange code convention in his job: almost every single method looks like this
//method head
{
try {
//actual method body
}
catch (...) {
}
}directly after the head opens a
tryblock over the whole body. all errors are just thrown away. the programs work and never crash! they are world market leader :-D seems this fast and easy developing is quite successfull at all. they are more engineers, so these kludges seem appropriate.modified on Thursday, July 1, 2010 2:57 PM
try{} catch{} blocks should be use only when you need it. Else there will be a performance issue. It is not recommended to write try catch block for the whole code of any method. Where you expect to be a codeflaw, where exception may come just put your try catch there. Don't try to use generic exception in all the case. If you know some specific exception that may come, only catch those explicitly.
Don't forget to Click on [Vote] and [Good Answer] on the posts that helped you.
Regards - Kunal Chowdhury | Software Developer | Chennai | India | My Blog | My Tweets | Silverlight Tutorial
-
a fellow student told me of a strange code convention in his job: almost every single method looks like this
//method head
{
try {
//actual method body
}
catch (...) {
}
}directly after the head opens a
tryblock over the whole body. all errors are just thrown away. the programs work and never crash! they are world market leader :-D seems this fast and easy developing is quite successfull at all. they are more engineers, so these kludges seem appropriate.modified on Thursday, July 1, 2010 2:57 PM
What you don't see, can't hurt you... It'll only hurt the guy who has to fix it.
-
I think it's true that failures related to some less significant features should not be allowed to disrupt other features. Even logging these failures in a production environment can impact other critical systems. So, there are probably legitimate cases where errors related to an entire subsystem should be squelched in the production build. Doing this is, at some level, a revival of
ON ERROR RESUME NEXT. At a minimum, I think that good programming practices dictate that unhandled exceptions should halt the program in its development builds (even if some of these are squelched in the "release" build). So long as the transition between build modes is automatic and reliable, this can be a good approach to exception handling for some applications._beauw_ wrote:
Even logging these failures in a production environment can impact other critical systems.
..logging doesn't require much resources (a small ringbuffer?), and should not influence the working of dependent systems. Having a global error handler that logs anything that's not expected helps a lot when maintaining the application.
I are Troll :suss:
-
Jon Sagara wrote:
Try/Swallow
I'm scared to reply to that one!
Dave
If this helped, please vote & accept answer!
Binging is like googling, it just feels dirtier. Please take your VB.NET out of our nice case sensitive forum.(Pete O'Hanlon)
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)DaveyM69 wrote:
Jon Sagara wrote: Try/Swallow I'm scared to reply to that one! Dave
Promise, it won't swallow you, Dave. ;P
Yusuf May I help you?
-
RugbyLeague wrote:
a great way to give the user the perception that all is right with the world.
That's the goal, according to some of the teachers here. If you find yourself in such a group, by all means, adapt or leave - you'll be the source of all bugs and errors if you try to move to structured error-handling :)
I are Troll :suss:
Eddy Vluggen wrote:
you'll be the source of all bugs and errors if you try to move to structured error-handling Smile
Fair point.
Steve
-
a fellow student told me of a strange code convention in his job: almost every single method looks like this
//method head
{
try {
//actual method body
}
catch (...) {
}
}directly after the head opens a
tryblock over the whole body. all errors are just thrown away. the programs work and never crash! they are world market leader :-D seems this fast and easy developing is quite successfull at all. they are more engineers, so these kludges seem appropriate.modified on Thursday, July 1, 2010 2:57 PM
-
RugbyLeague wrote:
a great way to give the user the perception that all is right with the world.
That's the goal, according to some of the teachers here. If you find yourself in such a group, by all means, adapt or leave - you'll be the source of all bugs and errors if you try to move to structured error-handling :)
I are Troll :suss:
Eddy Vluggen wrote:
you'll be the source of all bugs and errors if you try to move to structured error-handling
so right^^ once turning on printing error messages to stderr, there was so much outpu - it was turned off immediately :laugh:
-
_beauw_ wrote:
Even logging these failures in a production environment can impact other critical systems.
..logging doesn't require much resources (a small ringbuffer?), and should not influence the working of dependent systems. Having a global error handler that logs anything that's not expected helps a lot when maintaining the application.
I are Troll :suss:
If you mean to say that every exception should be logged in every piece of software, or even in every .NET application, I just cannot endorse that view. Logging is I/O, which is a failure-prone and time-consuming category of operation. Consider what happens if I attempt to log inside of a deeply nested loop; some very bad things could happen, if the loop needs to continue executing on a real-time basis. In the "debug" build, everything can grind to a halt... in production, the time for that is over. Again, this is not necessarily a far-fetched scenario. There are .NET applications that control, or at least influence, real-time machinery. There are .NET programs that guide stock traders in real-time. Entering into an I/O routine is not always an acceptable response to failure in such environments, no matter how nice it sounds at the Airport Sheraton.
modified on Wednesday, July 14, 2010 7:43 PM