views:

238

answers:

4

I have a BO method that must do two operations to fulfill its contract.

  1. insert a record into the db
  2. send an email notification containing the metadata for the record

Both are handled with calls to individual DAO methods responsible for completing the action.

I do not trap exceptions in my DAO, I handle and publish them in the BO. The first call is to the DAO to insert, and can throw a NullReferenceException or one of the sql exceptions. The email method uses SmtpClient.Send which can throw a slew of exceptions.

Is it possible to force the child method that calls the email functionality to return only one type of exception, a custom one, through an attribute?

To illustrate this:

public void AddSupportTicket(SupportTicketDTO ticket)
{
    try
    {
        supportTicketDAO.Insert(ticket);
        email.SendNotification(ticket);
    }
    catch (ExceptionA exc) { ... } // both of the methods can throw exceptions that
    catch (ExceptionB exc) { ... } // can overlap.  I just care about returning       
    catch (ExceptionC exc) { ... } // a custom EmailException or DataException
}

I can wrap each child method call in its own try catch and throw the custom exception I want, but thats just another level of try catch that gets trapped by another try catch in AddSupportTicket, and then one in the UI to redirect to an intelligent error, so that doesn't sound great to me.

How should I efficiently throw the correct custom exception?

A: 

Don't know about an attribute but you could you not just do:

try{
...
} catch(Exception ex) {

  throw new MyException("Some biz msg", ex);
}
Preet Sangha
+1  A: 

Yes, it's very possible. Check out Enterprise Library exception handling block. Lots of great stuff on raising, wrapping, logging exceptions from and between layers as well as setting up policies so you can handle it in configuration if you want to. Combined with the logging application block, it's a powerful combination.

JP Alioto
I like the approach of the Enterprise Library but have been holding off on using it for exceptions so I can focus getting other things moving. But its a great approach overall, +1
blu
A: 

C# does not provide functionality like Java's throws keyword, if that's what you're referring to. You can document the sorts of exceptions that your code my throw via the XML documentation standards, but there's no way to contractually force this.

Your best bet is proper documentation and intelligent exception handling at all levels of your application, as glib as that sounds.

Adam Robinson
+1  A: 

If your using WCF you can specify what kind of exception can be thrown from a given function, so in your service interface you would have something like

[OperationContract]
[FaultContract(typeof(MemberAlreadyExistsException))]
void MemberInsert(Member mu);
Rorzilla
I like this but my layers are referenced assemblies and not surfaced by services. I do like the approach for multiple load balanced web boxes however. +1
blu