a coder named Floris

Hi,..

Have you ever heard of “if it ain’t broke it’s bleeding inside” ?

This might be the case for your program, many of us use the try catch statement for catching exceptions. But you might be amazed by the shear number of exceptions that occur during runtime. We all know an exception is an exceptionally strong message that you need to respond to and not just smudge it away.

private void logMessage(string msg)
{
  try
  {
    File.AppendAllText(logfile, msg);
  }
  catch{} //ignore
}

There may be enough constructions like this throughout your code. When you throw an exception like that you need to think about this twice. At the very least tell other team members in comment why you did this.

So what happens when the drive is full? Well the entry is not written, but how bad is this?
What happens when the logfile value is configured (by app.config) with a non existing path? Is this a problem that needs to be handled?
What happens if you have insufficient rights to a certain location?

Think about it..

Let’s assume the”logMessage” function is not critical and we basicly do not care if does anything or not. You still have a performance issue. If the drive is full, why try to write again. Just set some flag and do not call File.AppendAllText… again.

Detecting the blood:

These are all just simple examples, endulge me and turn on the “Break when an exceptions is THROWN” Debug -> Exceptions, ath the “common Language Runtime Exceptions” check the Thrown and OK away. Now run your application.

If hardly nothing happens,.. good job!
If you feel like you are beeing shot at, time rethink some lines of code.