In a recent project there were several methods which performed various mathematical  calculations. One such method took in Doubles as parameters and performed several divides. According to the manner in which the method was written a Divide by Zero exception was to be caught if one of the doubles passed in was Zero. Unfortunately, no such exception was ever caught and strange results were being returned by the method thus corrupting the results of all calculations which called that method.

After some research I found out why. In C# Doubles are a form of Floating Point number, this means that they are to be used for scientific calculations and have been designed to never throw an exception because Zero is not their limit. According to the .Net documentation Doubles have a range supporting values from negative 1.79769313486232e308 to positive 1.79769313486232e308., this gives each Double a precision of ~29 digits. Because of this as the number approaches 0 it reaches a level of precision which is considered by the .net compiler as infinity and the results returned are either ‘Positive Infinity’ or ‘Negative Infinity’. Because Doubles are meant for Floating Point precision in scientific calculations you may need to select a less precise variable type to perform your calculations.

Knowing what can access your code as you write it and planning out the scope of access for your code is extremely important when it comes to the security of your code. In order to make sure your code is accessed as narrowly as possible increases the security or your code while decreasing the vulnerability at the same time. Here are the default access modifiers found in C#:

Definition: Class(es) => C# objects

Definition: Member(s) => variables, properties, methods

public: any and all code has access to classes or members which are public
private: the class or member is NOT accessible outside of itself  or the class that contains it
protected: the class or member is only accessible by the class that contains it or any class which is a decendant of that class (i.e. subclass)
internal: the class or member is only accessible by code that is within the same assembly (in other words .dll)
protected internal: the class or member is accessible by code in the same assembly (.dll) or by any subclass of that class that contains it.

There are a lot of programmers out there who are unaware of what really happens when they re-throw Exceptions within their applications and that there are 2 ways in which it can be done. Based on what you are trying to accomplish there is a right way and a wrong way.

Lets say you are using an error/exception logging system and you want to make sure and preserve everything that happened when the Exception was thrown as well as the code which caused it. To get to the logging system you may be bubbling up the Exceptions through your code to a main Exception Handler.

Here is the most common re-throwing of exceptions which I have seen in my own earlier code as well as those developers whose code I have worked on.

 try { //your code does something bad }
 catch (Exception ex) { throw ex; }

Discussion: the above code actually creates a brand new Exception within the current scope, this effectively deletes the Stack Trace held within the bubbling Exception. You have now lost all the information telling you what happened when the Exception was thrown and what code caused it. This is very bad when bubbling your Exceptions for logging.

try { //Your code does something bad }
catch (Exception ex) { throw; }

Discussion: The above code now just passes along any exception which is caught in the try-catch preserving the entire Stack Trace for your debugging enjoyment. This is very good when bubbling your Exceptions for logging.

Example code for sending emails in .Net using C#:

      //Send email
      try
      {
        MailMessage message = new MailMessage();
        message.From = new MailAddress(localizedContent.SendPasswordFromEmailAddress);
        MailAddressCollection toAddresses = message.To;
        toAddresses.Add(new MailAddress(_userInfo.Email));
        message.Subject = localizedContent.SendPasswordEmailSubject;
        message.Priority = MailPriority.Normal;
        message.BodyEncoding = Encoding.UTF8;
        message.Body = template;
        message.IsBodyHtml = true;       
        SmtpClient smtp = new SmtpClient(AppConfiguration.SmtpServer);
        smtp.Send(message);
        return true;
      }
      catch (Exception ex)
      {
        return false;
      }