Exception handling
-
Why do so many think that try - catch blocks are just here to stop you from seeing runtime errors? It is a plain nightmare to debug a project which has code like this sprinkled all over the place. (Note: I removed some confidental information from the code)
try
{
if (SomeConstant != "")
{
this.comboBox.SelectedItem = this.comboBox.Items[this.comboBox.Items.IndexOf(SomeConstant)];
}
}
catch { }Or one of my favourites:
protected override bool Exists()
{
bool returnValue = false;
try
{
// guess what happens when the webservice access throws an exception...
product = GetProductOverWebservice()if (product != null && product.product\_id == m\_RecordID.ToString()) { \_product = productinfo; returnValue = true; } } catch (Exception ex) { //great, just comment the only thing that could tell at least that an error occured //base.DebugWrite("\\tError: " + ex.ToString(), MODUL\_NAME); } return returnValue;}
I agree with your two examples... but there have been a couple of times where I have done the same thing because I don't want an exception. perhaps a file access on start up that is not important if it fails, I don't want to inform the user and I certainly don't want to crash the application. it is only on rare occasions thou Yes, I know I could log the error but maybe it really is that unimportant, plus perhaps my error logging process would have an empty catch if it fails to write to a log file (after all, can't log if the logging is failing)
This will do for now
-
Why do so many think that try - catch blocks are just here to stop you from seeing runtime errors? It is a plain nightmare to debug a project which has code like this sprinkled all over the place. (Note: I removed some confidental information from the code)
try
{
if (SomeConstant != "")
{
this.comboBox.SelectedItem = this.comboBox.Items[this.comboBox.Items.IndexOf(SomeConstant)];
}
}
catch { }Or one of my favourites:
protected override bool Exists()
{
bool returnValue = false;
try
{
// guess what happens when the webservice access throws an exception...
product = GetProductOverWebservice()if (product != null && product.product\_id == m\_RecordID.ToString()) { \_product = productinfo; returnValue = true; } } catch (Exception ex) { //great, just comment the only thing that could tell at least that an error occured //base.DebugWrite("\\tError: " + ex.ToString(), MODUL\_NAME); } return returnValue;}
Example of what I have seen...
Try
' This code starts up a form.
Catch oE as Exception
' Do nothing. If the form does not start you'll notice soon enough.
End TryThe comment in the Catch is taken almost literally from the code! I found it when I pasted a new form in the application and it did not start up. Well, at least the Catch was right in that I noticed soon enough :laugh: Don't really know what oE is. I guess ex was not obvious enough ;P Even worse is when I am forced to use company classes that catch and handle errors without giving them back. They usually log an error, end of story. How am I supposed to notify the user about any errors if my classes do not give me back an Exception? :confused: The worst part is that the application usually lacks any form design making class A depend on B and C, B on C and A, and C on A and B. So when I change a class (like removing unnecessary Catch blocks or rethrowing an Exception)... Well, who knows what might happen :(
It's an OO world.
-
Example of what I have seen...
Try
' This code starts up a form.
Catch oE as Exception
' Do nothing. If the form does not start you'll notice soon enough.
End TryThe comment in the Catch is taken almost literally from the code! I found it when I pasted a new form in the application and it did not start up. Well, at least the Catch was right in that I noticed soon enough :laugh: Don't really know what oE is. I guess ex was not obvious enough ;P Even worse is when I am forced to use company classes that catch and handle errors without giving them back. They usually log an error, end of story. How am I supposed to notify the user about any errors if my classes do not give me back an Exception? :confused: The worst part is that the application usually lacks any form design making class A depend on B and C, B on C and A, and C on A and B. So when I change a class (like removing unnecessary Catch blocks or rethrowing an Exception)... Well, who knows what might happen :(
It's an OO world.
-
Example of what I have seen...
Try
' This code starts up a form.
Catch oE as Exception
' Do nothing. If the form does not start you'll notice soon enough.
End TryThe comment in the Catch is taken almost literally from the code! I found it when I pasted a new form in the application and it did not start up. Well, at least the Catch was right in that I noticed soon enough :laugh: Don't really know what oE is. I guess ex was not obvious enough ;P Even worse is when I am forced to use company classes that catch and handle errors without giving them back. They usually log an error, end of story. How am I supposed to notify the user about any errors if my classes do not give me back an Exception? :confused: The worst part is that the application usually lacks any form design making class A depend on B and C, B on C and A, and C on A and B. So when I change a class (like removing unnecessary Catch blocks or rethrowing an Exception)... Well, who knows what might happen :(
It's an OO world.
-
An idea for "oE" might be: "obscure Exception". The lowercase "o" is to keep it as obscure as possible. :laugh:
-
Example of what I have seen...
Try
' This code starts up a form.
Catch oE as Exception
' Do nothing. If the form does not start you'll notice soon enough.
End TryThe comment in the Catch is taken almost literally from the code! I found it when I pasted a new form in the application and it did not start up. Well, at least the Catch was right in that I noticed soon enough :laugh: Don't really know what oE is. I guess ex was not obvious enough ;P Even worse is when I am forced to use company classes that catch and handle errors without giving them back. They usually log an error, end of story. How am I supposed to notify the user about any errors if my classes do not give me back an Exception? :confused: The worst part is that the application usually lacks any form design making class A depend on B and C, B on C and A, and C on A and B. So when I change a class (like removing unnecessary Catch blocks or rethrowing an Exception)... Well, who knows what might happen :(
It's an OO world.
Naerling wrote:
Don't really know what
oEisThat's
obvious Enough, isn't it? -
An idea for "oE" might be: "obscure Exception". The lowercase "o" is to keep it as obscure as possible. :laugh:
The Dutch (yes, I'm from the Netherlands) word for 'unknown' is 'Onbekend' and the Dutch word for 'unexpected' is 'Onverwacht'... So maybe I should have translated oE to uE? :^) I love all the guesses coming in though, keep them coming! :laugh:
It's an OO world.
-
Example of what I have seen...
Try
' This code starts up a form.
Catch oE as Exception
' Do nothing. If the form does not start you'll notice soon enough.
End TryThe comment in the Catch is taken almost literally from the code! I found it when I pasted a new form in the application and it did not start up. Well, at least the Catch was right in that I noticed soon enough :laugh: Don't really know what oE is. I guess ex was not obvious enough ;P Even worse is when I am forced to use company classes that catch and handle errors without giving them back. They usually log an error, end of story. How am I supposed to notify the user about any errors if my classes do not give me back an Exception? :confused: The worst part is that the application usually lacks any form design making class A depend on B and C, B on C and A, and C on A and B. So when I change a class (like removing unnecessary Catch blocks or rethrowing an Exception)... Well, who knows what might happen :(
It's an OO world.
-
Why do so many think that try - catch blocks are just here to stop you from seeing runtime errors? It is a plain nightmare to debug a project which has code like this sprinkled all over the place. (Note: I removed some confidental information from the code)
try
{
if (SomeConstant != "")
{
this.comboBox.SelectedItem = this.comboBox.Items[this.comboBox.Items.IndexOf(SomeConstant)];
}
}
catch { }Or one of my favourites:
protected override bool Exists()
{
bool returnValue = false;
try
{
// guess what happens when the webservice access throws an exception...
product = GetProductOverWebservice()if (product != null && product.product\_id == m\_RecordID.ToString()) { \_product = productinfo; returnValue = true; } } catch (Exception ex) { //great, just comment the only thing that could tell at least that an error occured //base.DebugWrite("\\tError: " + ex.ToString(), MODUL\_NAME); } return returnValue;}
It once took me 2 days! to track down a bug because someone had decided to swallowed the exception
catch { }. The problem is some programmers just don't get it. The best article I've ever read regarding exception handling is Exception Handling Best Practices and it's on CodeProject."You get that on the big jobs."
-
It once took me 2 days! to track down a bug because someone had decided to swallowed the exception
catch { }. The problem is some programmers just don't get it. The best article I've ever read regarding exception handling is Exception Handling Best Practices and it's on CodeProject."You get that on the big jobs."
Two days to track down an exception :wtf: There is an option in Visual Studio that takes you to the specific line of code where the exception occured as soon as it occurs (so when in debug mode). Not sure where to find it, but my keyboard shortcut is ctrl + alt + e (but that may vary per country or VS) :thumbsup: Of course I have no idea if other programs have it too. Excellent article btw! :thumbsup:
It's an OO world.
-
Two days to track down an exception :wtf: There is an option in Visual Studio that takes you to the specific line of code where the exception occured as soon as it occurs (so when in debug mode). Not sure where to find it, but my keyboard shortcut is ctrl + alt + e (but that may vary per country or VS) :thumbsup: Of course I have no idea if other programs have it too. Excellent article btw! :thumbsup:
It's an OO world.
Hi Naerling, The problem is you may not be aware that it is an exception that is the problem. In this case it smelt like business logic because no exceptions where being thrown or logged. The Exception window is a great tool. It can be found in the menu bar under Debug, Exceptions...
"You get that on the big jobs."
-
Example of what I have seen...
Try
' This code starts up a form.
Catch oE as Exception
' Do nothing. If the form does not start you'll notice soon enough.
End TryThe comment in the Catch is taken almost literally from the code! I found it when I pasted a new form in the application and it did not start up. Well, at least the Catch was right in that I noticed soon enough :laugh: Don't really know what oE is. I guess ex was not obvious enough ;P Even worse is when I am forced to use company classes that catch and handle errors without giving them back. They usually log an error, end of story. How am I supposed to notify the user about any errors if my classes do not give me back an Exception? :confused: The worst part is that the application usually lacks any form design making class A depend on B and C, B on C and A, and C on A and B. So when I change a class (like removing unnecessary Catch blocks or rethrowing an Exception)... Well, who knows what might happen :(
It's an OO world.
Naerling wrote:
Don't really know what oE is
I guess it means "objectException", in an extra nasty form of hungarian notation.
-
Hi Naerling, The problem is you may not be aware that it is an exception that is the problem. In this case it smelt like business logic because no exceptions where being thrown or logged. The Exception window is a great tool. It can be found in the menu bar under Debug, Exceptions...
"You get that on the big jobs."
Actually, the catch that said 'Do nothing, if the form does not start you will know soon enough' (see a previous post) did nothing because some forms were started and disposed immediatly, or gave the user the option to end it while it was still loading. This, of course, gave an exception. But because it was meant to behave like that the programmer did not want to do anything with the exception... So when I fixed it by showing a messagebox and logging the exception I actually got told to undo my changes because 'the business logic was designed that way'! How about that for business logic? ;P
It's an OO world.
-
Example of what I have seen...
Try
' This code starts up a form.
Catch oE as Exception
' Do nothing. If the form does not start you'll notice soon enough.
End TryThe comment in the Catch is taken almost literally from the code! I found it when I pasted a new form in the application and it did not start up. Well, at least the Catch was right in that I noticed soon enough :laugh: Don't really know what oE is. I guess ex was not obvious enough ;P Even worse is when I am forced to use company classes that catch and handle errors without giving them back. They usually log an error, end of story. How am I supposed to notify the user about any errors if my classes do not give me back an Exception? :confused: The worst part is that the application usually lacks any form design making class A depend on B and C, B on C and A, and C on A and B. So when I change a class (like removing unnecessary Catch blocks or rethrowing an Exception)... Well, who knows what might happen :(
It's an OO world.
-
Naerling wrote:
Don't really know what oE is
I guess it means "objectException", in an extra nasty form of hungarian notation.
-
It once took me 2 days! to track down a bug because someone had decided to swallowed the exception
catch { }. The problem is some programmers just don't get it. The best article I've ever read regarding exception handling is Exception Handling Best Practices and it's on CodeProject."You get that on the big jobs."
RobCroll wrote:
The problem is some programmers just don't get it.
Unfortunately, it's usually the customers who don't get it. Our code is full of this "non-specific" error handling - not because we are bad programmers, but because customers don't want to see error messages (we've had complaints, such as "It's telling me that the socket has refused the connection! I don't want to see it!"). To me, that is stupid - I'd rather see a problem instead of sitting around wondering why something isn't working. On the other hand, we work a lot with real-time data, so customers don't want it constantly stopped by dialog boxes intimating that their system is badly set up (as it usually is)! At least all our exceptions are logged - a small scrap of comfort for us.
-
RobCroll wrote:
The problem is some programmers just don't get it.
Unfortunately, it's usually the customers who don't get it. Our code is full of this "non-specific" error handling - not because we are bad programmers, but because customers don't want to see error messages (we've had complaints, such as "It's telling me that the socket has refused the connection! I don't want to see it!"). To me, that is stupid - I'd rather see a problem instead of sitting around wondering why something isn't working. On the other hand, we work a lot with real-time data, so customers don't want it constantly stopped by dialog boxes intimating that their system is badly set up (as it usually is)! At least all our exceptions are logged - a small scrap of comfort for us.
Some of the exceptions I get I don't understand! So what chance does a user have. They just don't understand the message. I like to encapsulate the error message in the business layer and throw a more user friendly error message to the presentation layer “Could not save customer information because computer networks are down.”. Users understand that. They have no idea of what a TCP/IP socket is but they understand that networks aren't always working. That's the problem. It's not that there is a problem but the the message is meaningless. They don't understand the message. So whether you are implementing MVC or MVVM or whatever, at some stage you need to consider the message the user gets. Once they understand the problem, it's all cool... “see your Systems Administrator”. Now who the hell is that? :) BTW that small scrap would be a life saver.
"You get that on the big jobs."
-
Why do so many think that try - catch blocks are just here to stop you from seeing runtime errors? It is a plain nightmare to debug a project which has code like this sprinkled all over the place. (Note: I removed some confidental information from the code)
try
{
if (SomeConstant != "")
{
this.comboBox.SelectedItem = this.comboBox.Items[this.comboBox.Items.IndexOf(SomeConstant)];
}
}
catch { }Or one of my favourites:
protected override bool Exists()
{
bool returnValue = false;
try
{
// guess what happens when the webservice access throws an exception...
product = GetProductOverWebservice()if (product != null && product.product\_id == m\_RecordID.ToString()) { \_product = productinfo; returnValue = true; } } catch (Exception ex) { //great, just comment the only thing that could tell at least that an error occured //base.DebugWrite("\\tError: " + ex.ToString(), MODUL\_NAME); } return returnValue;}
