Another error handling question - best practice?

[James Radke]

Hello,

I am looking for guidance on best practices to incorporate effective and complete error handling in an application written in VB.NET. If I have the following function in a class module (note that this class module represents the business layer of code NOT the gui layer):

Public Function Test(ByVal Parm1 As Integer, ByVal Parm2 As Integer) As SqlDataReader
' Declare the SQL data layer class
Dim oSQL As New SqlService(ConnectionString)

' Add the parameters to the command object
oSQL.AddParameter("@Parm1", SqlDbType.SmallInt, 0, Parm1, ParameterDirection.Input)
oSQL.AddParameter("@Parm2", SqlDbType.SmallInt, 0, Parm2, ParameterDirection.Input)

' Run the stored procedure and return a datareader
Return oSQL.RunProcReader("SQLStoredProcedureName")
End Function

which is calling the following library function (data access layer of code) which can/could throw an exception (which I believe already has valid error handling in it):

Public Function RunProcReader(ByVal sProcName As String) As SqlDataReader
' Check to make sure we have all the data necessary for a connection
If Not IsValidConnectionString() Then
Throw New InvalidConnectionException("Invalid SQL connection string: " & ConnectionString)
End If

Dim dr As SqlDataReader '//--- Create a new sqlDataReader
Dim oCmd As SqlCommand = New SqlCommand '//--- Create a new SqlCommand
Dim oCn As SqlConnection = Nothing '//--- Declare the SqlConnection
Dim oSqlParameter As SqlParameter = Nothing '//--- Declare a SqlParameter
Dim oP As Parameter = Nothing '//--- Declare a Parameter

'Get an enumerator for the parameter array list
Dim oEnumerator As IEnumerator = m_oParmList.GetEnumerator()

Try
'Prepare connection to the database
oCn = Connect()

With oCmd
.Connection = oCn
.CommandText = sProcName
.CommandType = CommandType.StoredProcedure
End With

'Add the parameters to the command
AddParameters(oEnumerator, oCmd)

' Open the connection
oCn.Open()

' Execute the datareader, and close the connection
dr = oCmd.ExecuteReader(CommandBehavior.CloseConnection )
Catch ex As Exception
Throw
Finally
Disconnect(oCn)
End Try

'Get the output parameter values if there were no errors
GetOutputParameterValues(oCmd)

'Return the DataReader
Return dr
End Function

How would we add error handling into the Test function above to be able to gracefully handle the errors encountered in the data access layer (RunProcReader) AND to gracefully send the error back to the gui calling program? Do we just simply enclose everything in a try catch, and then also enclose the call to the Test function (from the GUI layer) within a try catch block so that if an error is encountered we can gracefully handle the presentation?

Anyone care to provide us with ideas as to what you are doing in similar circumstances?

Jim

[Rob Windsor]

Hi James,

Methods in your business layer should only be catching errors if they can
deal with the error internally (not very common) or they can add valuable
information to they error on it's way up to the UI layer. For example,
RunProcReader should not have a catch block (just a try...finally) because
it is not adding any information that the handling method can use, you are
just adding extra overhead without adding any extra value.

What you could do instead is have RunProcReader catch the exception and then
throw a custom exception that has properties like the name of the stored
procedure and the connection string. If you do this make sure to include the
original exception as the InnerException.

There's a good chapter on exception handling in Jeffrey Richter's "Applied
Microsoft.NET Framework Programming" (Microsoft Press) .

Hope this helps.

--
Rob Windsor
G6 Consulting
Toronto, Canada

"James Radke" <jr*****@wi.rr.com> wrote in message
news:e1**************@TK2MSFTNGP10.phx.gbl...
Hello,

I am looking for guidance on best practices to incorporate effective and
complete error handling in an application written in VB.NET. If I have the
following function in a class module (note that this class module represents
the business layer of code NOT the gui layer):

Public Function Test(ByVal Parm1 As Integer, ByVal Parm2 As Integer) As
SqlDataReader
' Declare the SQL data layer class
Dim oSQL As New SqlService(ConnectionString)

' Add the parameters to the command object
oSQL.AddParameter("@Parm1", SqlDbType.SmallInt, 0, Parm1,
ParameterDirection.Input)
oSQL.AddParameter("@Parm2", SqlDbType.SmallInt, 0, Parm2,
ParameterDirection.Input)

' Run the stored procedure and return a datareader
Return oSQL.RunProcReader("SQLStoredProcedureName")
End Function

which is calling the following library function (data access layer of code)
which can/could throw an exception (which I believe already has valid error
handling in it):

Public Function RunProcReader(ByVal sProcName As String) As
SqlDataReader
' Check to make sure we have all the data necessary for a
connection
If Not IsValidConnectionString() Then
Throw New InvalidConnectionException("Invalid SQL connection
string: " & ConnectionString)
End If

Dim dr As SqlDataReader '//---
Create a new sqlDataReader
Dim oCmd As SqlCommand = New SqlCommand '//---
Create a new SqlCommand
Dim oCn As SqlConnection = Nothing '//---
Declare the SqlConnection
Dim oSqlParameter As SqlParameter = Nothing '//---
Declare a SqlParameter
Dim oP As Parameter = Nothing '//---
Declare a Parameter

'Get an enumerator for the parameter array list
Dim oEnumerator As IEnumerator = m_oParmList.GetEnumerator()

Try
'Prepare connection to the database
oCn = Connect()

With oCmd
.Connection = oCn
.CommandText = sProcName
.CommandType = CommandType.StoredProcedure
End With

'Add the parameters to the command
AddParameters(oEnumerator, oCmd)

' Open the connection
oCn.Open()

' Execute the datareader, and close the connection
dr = oCmd.ExecuteReader(CommandBehavior.CloseConnection )
Catch ex As Exception
Throw
Finally
Disconnect(oCn)
End Try

'Get the output parameter values if there were no errors
GetOutputParameterValues(oCmd)

'Return the DataReader
Return dr
End Function

How would we add error handling into the Test function above to be able to
gracefully handle the errors encountered in the data access layer
(RunProcReader) AND to gracefully send the error back to the gui calling
program? Do we just simply enclose everything in a try catch, and then also
enclose the call to the Test function (from the GUI layer) within a try
catch block so that if an error is encountered we can gracefully handle the
presentation?

Anyone care to provide us with ideas as to what you are doing in similar
circumstances?

Jim

[James Radke]

Rob,

If you only use the Try.. Finally without a catch wouldn't my program
"abend" without the catch as soon as a problem is encountered?

Jim
"Rob Windsor" <rw******@NO.MORE.SPAM.bigfoot.com> wrote in message
news:OD**************@TK2MSFTNGP10.phx.gbl...

Hi James,

Methods in your business layer should only be catching errors if they can
deal with the error internally (not very common) or they can add valuable
information to they error on it's way up to the UI layer. For example,
RunProcReader should not have a catch block (just a try...finally) because
it is not adding any information that the handling method can use, you are
just adding extra overhead without adding any extra value.

What you could do instead is have RunProcReader catch the exception and then throw a custom exception that has properties like the name of the stored
procedure and the connection string. If you do this make sure to include the original exception as the InnerException.

There's a good chapter on exception handling in Jeffrey Richter's "Applied
Microsoft.NET Framework Programming" (Microsoft Press) .

Hope this helps.

--
Rob Windsor
G6 Consulting
Toronto, Canada

"James Radke" <jr*****@wi.rr.com> wrote in message
news:e1**************@TK2MSFTNGP10.phx.gbl...
Hello,

I am looking for guidance on best practices to incorporate effective and
complete error handling in an application written in VB.NET. If I have the following function in a class module (note that this class module represents the business layer of code NOT the gui layer):

Public Function Test(ByVal Parm1 As Integer, ByVal Parm2 As Integer) As SqlDataReader
' Declare the SQL data layer class
Dim oSQL As New SqlService(ConnectionString)

' Add the parameters to the command object
oSQL.AddParameter("@Parm1", SqlDbType.SmallInt, 0, Parm1,
ParameterDirection.Input)
oSQL.AddParameter("@Parm2", SqlDbType.SmallInt, 0, Parm2,
ParameterDirection.Input)

' Run the stored procedure and return a datareader
Return oSQL.RunProcReader("SQLStoredProcedureName")
End Function

which is calling the following library function (data access layer of code) which can/could throw an exception (which I believe already has valid error handling in it):

Public Function RunProcReader(ByVal sProcName As String) As
SqlDataReader
' Check to make sure we have all the data necessary for a
connection
If Not IsValidConnectionString() Then
Throw New InvalidConnectionException("Invalid SQL connection string: " & ConnectionString)
End If

Dim dr As SqlDataReader '//---
Create a new sqlDataReader
Dim oCmd As SqlCommand = New SqlCommand '//---
Create a new SqlCommand
Dim oCn As SqlConnection = Nothing '//---
Declare the SqlConnection
Dim oSqlParameter As SqlParameter = Nothing '//---
Declare a SqlParameter
Dim oP As Parameter = Nothing '//---
Declare a Parameter

'Get an enumerator for the parameter array list
Dim oEnumerator As IEnumerator = m_oParmList.GetEnumerator()

Try
'Prepare connection to the database
oCn = Connect()

With oCmd
.Connection = oCn
.CommandText = sProcName
.CommandType = CommandType.StoredProcedure
End With

'Add the parameters to the command
AddParameters(oEnumerator, oCmd)

' Open the connection
oCn.Open()

' Execute the datareader, and close the connection
dr = oCmd.ExecuteReader(CommandBehavior.CloseConnection )
Catch ex As Exception
Throw
Finally
Disconnect(oCn)
End Try

'Get the output parameter values if there were no errors
GetOutputParameterValues(oCmd)

'Return the DataReader
Return dr
End Function

How would we add error handling into the Test function above to be able to
gracefully handle the errors encountered in the data access layer
(RunProcReader) AND to gracefully send the error back to the gui calling
program? Do we just simply enclose everything in a try catch, and then also enclose the call to the Test function (from the GUI layer) within a try
catch block so that if an error is encountered we can gracefully handle the presentation?

Anyone care to provide us with ideas as to what you are doing in similar
circumstances?

Jim

[Chris Dunaway]

"James Radke" <jr*****@wi.rr.com> wrote in
news:uC*************@TK2MSFTNGP10.phx.gbl:

Rob,

If you only use the Try.. Finally without a catch wouldn't my program
"abend" without the catch as soon as a problem is encountered?

No, it should be caught by an exception handler higher up the call stack.
If there is no exception handler higher up, then it would probably "abend"

Chris

[Rob Windsor]

No. When an exception occurs .NET will walk the call stack until it finds
the first method that has an enclosing catch block. Because many of your
business objects will not be catching errors but still need to ensure
resources are released you will see about a 10-1 ratio of try...finally to
try...catch blocks. In the UI the ratio of try...catch is considerably
higher.

I took a quick look and I found this article at the link below which
discusses error handling in a little bit more detail. I'm sure there are
other free resources out there as well.

http://msdn.microsoft.com/msdnmag/is...s/default.aspx

Rob

"James Radke" <jr*****@wi.rr.com> wrote in message
news:uC*************@TK2MSFTNGP10.phx.gbl...

Rob,

If you only use the Try.. Finally without a catch wouldn't my program
"abend" without the catch as soon as a problem is encountered?

Jim
"Rob Windsor" <rw******@NO.MORE.SPAM.bigfoot.com> wrote in message
news:OD**************@TK2MSFTNGP10.phx.gbl...

Hi James,

Methods in your business layer should only be catching errors if they can deal with the error internally (not very common) or they can add valuable information to they error on it's way up to the UI layer. For example,
RunProcReader should not have a catch block (just a try...finally) because it is not adding any information that the handling method can use, you are just adding extra overhead without adding any extra value.

What you could do instead is have RunProcReader catch the exception and then

throw a custom exception that has properties like the name of the stored
procedure and the connection string. If you do this make sure to include

the

original exception as the InnerException.

There's a good chapter on exception handling in Jeffrey Richter's "Applied Microsoft.NET Framework Programming" (Microsoft Press) .

Hope this helps.

--
Rob Windsor
G6 Consulting
Toronto, Canada

"James Radke" <jr*****@wi.rr.com> wrote in message
news:e1**************@TK2MSFTNGP10.phx.gbl...
Hello,

I am looking for guidance on best practices to incorporate effective and
complete error handling in an application written in VB.NET. If I have

the

following function in a class module (note that this class module

represents

the business layer of code NOT the gui layer):

Public Function Test(ByVal Parm1 As Integer, ByVal Parm2 As Integer) As

SqlDataReader
' Declare the SQL data layer class
Dim oSQL As New SqlService(ConnectionString)

' Add the parameters to the command object
oSQL.AddParameter("@Parm1", SqlDbType.SmallInt, 0, Parm1,
ParameterDirection.Input)
oSQL.AddParameter("@Parm2", SqlDbType.SmallInt, 0, Parm2,
ParameterDirection.Input)

' Run the stored procedure and return a datareader
Return oSQL.RunProcReader("SQLStoredProcedureName")
End Function

which is calling the following library function (data access layer of

code)

which can/could throw an exception (which I believe already has valid

error

handling in it):

Public Function RunProcReader(ByVal sProcName As String) As
SqlDataReader
' Check to make sure we have all the data necessary for a
connection
If Not IsValidConnectionString() Then
Throw New InvalidConnectionException("Invalid SQL

connection

string: " & ConnectionString)
End If

Dim dr As SqlDataReader '//---
Create a new sqlDataReader
Dim oCmd As SqlCommand = New SqlCommand '//---
Create a new SqlCommand
Dim oCn As SqlConnection = Nothing '//---
Declare the SqlConnection
Dim oSqlParameter As SqlParameter = Nothing '//---
Declare a SqlParameter
Dim oP As Parameter = Nothing '//---
Declare a Parameter

'Get an enumerator for the parameter array list
Dim oEnumerator As IEnumerator = m_oParmList.GetEnumerator()

Try
'Prepare connection to the database
oCn = Connect()

With oCmd
.Connection = oCn
.CommandText = sProcName
.CommandType = CommandType.StoredProcedure
End With

'Add the parameters to the command
AddParameters(oEnumerator, oCmd)

' Open the connection
oCn.Open()

' Execute the datareader, and close the connection
dr = oCmd.ExecuteReader(CommandBehavior.CloseConnection )
Catch ex As Exception
Throw
Finally
Disconnect(oCn)
End Try

'Get the output parameter values if there were no errors
GetOutputParameterValues(oCmd)

'Return the DataReader
Return dr
End Function

How would we add error handling into the Test function above to be able

to gracefully handle the errors encountered in the data access layer
(RunProcReader) AND to gracefully send the error back to the gui calling
program? Do we just simply enclose everything in a try catch, and then

also

enclose the call to the Test function (from the GUI layer) within a try
catch block so that if an error is encountered we can gracefully handle

the

presentation?

Anyone care to provide us with ideas as to what you are doing in similar
circumstances?

Jim