Introduction
One of the main features of ASP.NET over ASP is
its new error handling features. The only way to capture errors in the
ASP/VBScript was using the "On Error Resume Next" statement and checking each
line for an error with "If Err.Number <> 0 Then " statements. Developers who
where using JScript instead of the VBScript at the server-side where lucky.
They've had access to the "Try... Catch" statements provided by JScript. Well
it's all over now. Now all the .NET enabled languages support better error
handling statements including VB.NET. Now, VB.NET supports the "Try...Catch"
statement. On top of this ASP.NET configuration file also supports ASP.NET level
error handling. Let's see all of them one by one.
VB.NET Error Handling
In the previous versions of VB we had several flavors of "On Error"
statements to handle error in a non-structured way. But in VB.NET we can make
use of the structured way of error handling with the Try & Catch statement. Here
is an example for this.
Sub DoSomething()
Try
'Do
Something
Catch e As Exception
'Catch
the error and display it.
Response.Write("An Error
Occurred: " & e.toString())
Finally
'Do the
final cleanup such as closing the Database connection
End Try
End Sub
The above code is the simplest form of structured error handling in VB.NET.
We're doing our processing in the Try Block. If anything goes wrong in the Try
block, the Catch block will be called and the error will be handled. After that
the "Finally" block will be called to do the cleanup.
We can also filter the error handling based on the type of exceptions. For
example, Let's say we're accessing data from SQL Server 2000 and we're writing
the data into a text file. In this process there could be three kids of error.
-
SQL
Server related Errors.
-
File IO
Errors.
-
Other generic errors.
We can filter the
errors based on their categories in the Catch block. Let's see an example for
this.
Sub DoSomething()
Try
'Do
Something
Catch SQLExp As SQLException
'Catch
the error and display it.
Response.Write("An SQL
Server Error Occurred: " & e.toString())
Catch IOExp As IOException
'Catch
the error and display it.
Response.Write("An File
IO Error Occurred: " & e.toString())
Catch e As Exception
'Catch
the error and display it.
Response.Write("An Error
Occurred: " & e.toString())
Finally
'Do the
final cleanup such as closing the Database connection
End Try
End Sub
As you can see we've
categorized our error handling based on the errors. The "Catch SQLExp as
SQLException" block will handle all the SQL Server errors and all File IO errors
will be handled by "Catch IOExp as IOException" block. The SQLException and
IOExpection classes are defined in the "System.Data.SQL" and "System.IO"
namespaces. We can further customize the errors based on the error numbers,
Sub DoSomething()
Try
'Do Something
Catch SQLExp As SQLException
If SQLExp.Number
= 1212 Then
Response.Write("SQL Server Error 1212 Occurred: " & e.toString())
Else
'Catch the
error and display it.
Response.Write("An SQL Server Error Occurred: " & e.toString())
End If
Catch IOExp As IOException
'Catch the
error and display it.
Response.Write("An File IO Error Occurred: " & e.toString())
Catch e As Exception
'Catch the
error and display it.
Response.Write("An Error Occured: " & e.toString())
Finally
'Do the final
cleanup such as closing the Database connection
End Try
End Sub
or
Sub DoSomething()
Try
'Do Something
Catch When Err
= 1212
Response.Write("SQL Server Error 1212 Occurred: " & e.toString())
Catch SQLExp As SQLException
'Catch the
error and display it.
Response.Write("An SQL Server
Error Occurred: " & e.toString())
Catch IOExp As IOException
'Catch the
error and display it.
Response.Write("An File IO
Error Occurred: " & e.toString())
Catch e As Exception
'Catch the
error and display it.
Response.Write("An Error
Occurred: " & e.toString())
Finally
'Do the final
cleanup such as closing the Database connection
End Try
End Sub
We can use the "Exit
Try" statement in the "Catch" block to exit from the "Try...Catch" structure.
ASP.NET Error Handling options
ASP.NET provides better support for tracking runtime errors and
handling them. This gives us more power to display customized messages to the
site users rather than seeing the error messages like "BC30311: A value of
type..." .
By default, when an error occurs in ASP.NET code, ASP.NET show the error message
and it'll also highlights the code line of code causing the error. For example,
in the page load event, we've used the following code.
Sub Page_Load(ByVal Src As Object, ByVal E As EventArgs)
Dim Myobj As New MyObject
Myobj.DoSomthing()
End Sub
MyObject was not defined in any of the namespaces. So, I should get a
compilation error. Here is how ASP.NET shows the error message.
ASP.NET shows the error message and it also shows
the line of code that causes the error including the line number. You'll see
this error message only if you are accessing the site locally like
"http://localhost/YourApp/". If you access the site with it's IP address likehttp://xx.xx.xx.xx/YourApp/ then,
you'll not see the above message. Instead you'll see something like this.
ASP.NET hides all your application information (Your code), when your site is
accessed from out side world. It only shows the application specific error
message if you access the site locally. When you are developing the ASP.NET
application, you may sit in a different machine than the one hosted the ASP.NET.
In these cases you may want to see the error messages outside of the local
machine also. Well, if you want to show the error messages outside the local
machine then you can set the set the <customerrors> tags mode attribute to "off"
in WEB.CONFIG?
<configuration>
<customerrors mode="
off " />
</configuration>
Custom Error page
The default message showed by ASP.NET may make sense in the development
environment and it many not make any sense to the end users of the site. In that
case, ASP.NET allows us to configure a default error-handling page for your
site. We can specify the error page like this in WEB.CONFIG.
<configuration>
<customerrors mode="on" defaultredirect="error.aspx" />
</configuration>
So, when
an un-handled error occurs in ASP.NET application "Error.ASPX" error page will
be displayed. After we've changed the configuration in the WEB.CONFIG, here is
how the above error pages looks like.
Of course, we can make this page prettier some meaningful content to the end
user of your site.
The mode attribute in the <customerrors> tag can have two options. The
difference is shown in the following table.
Mode attribute |
Localhost |
IP Address |
remoteonly |
The error
message from the compiler and the code that is causing the error
will be showed. |
Custom error page will be showed. |
on |
Custom
error page will be showed. |
Custom
error page will be showed. |
Final Note
ASP.NET and VB.NET both are providing excellent error handling options
when compared with ASP and VB6.
Until next time, Happy Programming!