In a MVP win forms application I’m handling exceptions as follows in DAL.
Since the user messaging is not a responsibility of DAL, I want to move it in to my Presentation class.
Could you show me a standard way to do that?
public bool InsertAccount(IBankAccount ba)
{
string selectStatement = @"IF NOT EXISTS (SELECT ac_no FROM BankAccount WHERE ac_no=@ac_no) BEGIN INSERT INTO BankAccount ...";
using (SqlConnection sqlConnection = new SqlConnection(db.ConnectionString))
{
using (SqlCommand sqlCommand = new SqlCommand(selectStatement, sqlConnection))
{
try
{
sqlConnection.Open();
sqlCommand.Parameters.Add("@ac_no", SqlDbType.Char).Value = ba.AccountNumber;
//
//
sqlCommand.ExecuteNonQuery();
return true;
}
catch (Exception e) { MessageBox.Show(("Error: " + e.Message)); }
if (sqlConnection.State == System.Data.ConnectionState.Open) sqlConnection.Close();
return false;
}
}
}
EDIT2 :
So based on the answers I re edited the post and now my exception handling code looks like this…
DAL
public bool InsertAccount(IBankAccount ba)
{
try
{
sqlConnection.Open();
//
}
catch (SqlException)
{
throw new Exception("DataBase related Exception occurred");
}
catch (Exception)
{
throw new Exception("Exception occurred");
}
}
BankAccountPresenter
private void SaveBankAccount()
{
try
{
_DataService.InsertAccount(_model);
}
catch (Exception e) { MessagingService.ShowErrorMessage(e.Message); }
}
Why I’ve caught exceptions in DAL is that even at the moment I’m not logging errors, I may have to do it in future.
And also this way I can differentiate the error massages in DAL, whether it’s sql related or general.
I’ve used messaging service in my presenter when showing error messages.
Does this meaning full? Can this be simplified?
Instead of catching the exception, why don’t you just let it bubble up to the calling code? So either your model or controller (depending on how you call InsertAccount) would have the ability to catch the exception (or, in fact, any exception) and display it to the user in an appropriate fashion.
My general rule is to only catch an exception when I can do something to fix it or I have no choice but to deal with it. Your DAL can’t fix it, and it has a choice: pass it to someone upstream to handle it.
To address your edit, I would discourage creating a new, generic exception and passing it up. What does that do for users? They only care that something has failed, not that it’s the database or another component. If you want to do error logging from inside your DAL (and I do think that’s a compelling reason to catch exceptions), catch it, log it, and then re-throw that exception up to the caller. That way you get the best of both worlds–you have handled the exception in an important way for your code, and your presenter can figure out how it wants to present the exception to the user.