explanation needed for exceptions/classes.

Question

Consider the following snippet:

  using System;
using System.Collections.Generic;
using System.Linq;
using System.Net;


namespace ForumLogins {
    public class VBULLETIN {

        HttpWebRequest request;


        public void ForumLogins(string url) {          
            request = (HttpWebRequest)WebRequest.Create(url);
        }
    }
}

According to MSDN the "Create" method can return 4 exceptions. Now I cant dissolve those exceptions.. because well otherwise the class wont function. But what should I do? Should I still wrap it in a try/catch block? and in the catch "throw a new exception".. or let the person who implments this class handle the exceptions?

Cuz this is a constructor .. and I guess constructors arnt really supposed to fail?

Answer 1

What you do depends on the role of the code. If this is a library that your going to share I'd recommend you wrap all exceptions and rethrow meaningful exceptions for your library. This will help you achieve implenentation encapsulation.

For example

try
{
   if (string.isNullOrEmpty(url))
   {
      //This will stop the arugment null exception and you can throw a meaningful message
   } 
    request = (HttpWebRequest)WebRequest.Create(url);
}
catch(SecurityException sex)
{
   //Can't handle this but maybee you can provide more information about how to configure security here...

     throw new YourCustomerException(msg,sex); //It's good practice to put the current exception in the inner exception
}

If your not building a component and this is your application then I recommend you somewhere along the stack catch the error, and log it.

Also this isn't a constructor your calling a Factory method on WebRequest called Create.

Answer 2

If your constructor can fail, then you should probably let the person who implements the class handle the errors. Just be sure to document the fact that it might fail so they know to try/catch.

On a related note, constructors should never fail. =)

Instead, put the logic that can possibly fail into a "Go()" method. That way you can instantiate a real class, but put a try/catch around segments of the code, and still reference the object outside of the try-catch block later. Just my $.02.

Answer 3

It looks to me like this code isn't the exact code you're going to be using, so I'm trying to answer your question based on what I can work out you're trying to ask.

I would recommend where possible, you handle the exception. If that's not possible, I think in your case the best approach would be to wrap the WebRequest.Create exception as the InnerException and rethrow it. That keeps the abstraction, while still making more detail available if necessary. Probably along the lines of this:

try{
    request = (HttpWebRequest)WebRequest.Create(url);
}
catch(Exception e) {
    throw new ForumLoginException(e);
}