I just wrote the stupidest program ever. It is inefficient by design. If anyone did this thinking “hey… this is great code” they should be fired.
Anyway… generally speaking, using try/catch blocks is not a great idea. There are a myriad of reasons but it’s usually something along the lines of:
If you truly have an unexpected error it’s better to let the program crash and then fix the bug.
If you do have to use the try/catch exception handling block, you should only catch explicit exceptions. For example catch a file access exception or a database invalid primary key exception. Just catching the generic exception is poor practice.
There’s another reason to avoid try/catch though… it is a performance hog.
In the search for better and better performance, there are many techniques developers can use. A technique used early on by some entry level or “still learning” developers is to build inline SQL. That looks something like this:
string name = "Mark";
string query = "SELECT * FROM users WHERE FirstName='" + name + "'";
OleDbCommand cmd = new OleDbCommand(query);
OleDbDataReader reader = cmd.ExecuteReader();
There are steps missing… this is just example code
This is something more seasoned developers learn to avoid almost immediately. There’s a variety of reasons why inline SQL is bad. The most important reason is security.
However, there’s another reason to avoid it. Performance.
All I can say is WOW.
Wow… I just removed log4net from my project. What a performance hog log4net is!
Let’s be clear… I had simply disabled log4net by turning the responders “OFF”. I never modified the code to check to see if debugging was enabled or anything like that. Just turning it “OFF” didn’t really help anything. I kept finding errors in the log that it was unable to get access to the log file like it wanted.
By commenting everything out, my performance jumped! I suppose at some point I’ll go back and add the logic to only log things if it’s turned on. Right now, I don’t need the logging so I’ll leave it disabled.