The quality of a website is not only judged by how well the website works but how gracefully it fails. When there is an error with ActiveReports it displays the error ( a stack trace ) in the web viewer in an alert box style box but leaves you as the developer limited in how you can handle the error or log the error. It is important to point out that an "Error" needs to be handled in different ways. We need to let the user know that there is a problem but we don't want to inform them via a stack dump. It is vice versa for the developers, they don't care that an error happened per se, but they are interested in what caused the error. Luckily we can completely customize the way we handle application errors in ActiveReports. Let's think of a scenario, you have a large website that integrates ActiveReports into it. Let's say our ActiveReports connects to a server to get its data. We, as developers, cannot be promised that the connection to our Database will always be valid, for many reasons outside our control. If our website loses connection to its database server, we don't want our Users to suffer from it by simply giving them a stack dump or a server error. We want to provide our users with ways to get assistance in resolving the issue. Also, we don't want our users knowing that there is an issue with the DB connection, we simply want to let them know that there is an issue and they can contact customer support to report the issue and get it resolved. This sample demonstrates how we can deal with these issues. This sample will show you how to handle errors with ActiveReports in a web environment. If there is an issue with ActiveReports, it will simply redirect the user to a custom error page that we can display IT contact information and also email the Errors to your support team or IT team without the user ever knowing. To begin we ned to tell our website that we want to handle errors in a custom manner. This can be accomplished by setting the web.config file properly. In our System.Web tag in our Web.config we need to add the following entry:
<customErrors mode="On" defaultRedirect="~/CustomErrors/Oops.aspx" redirectMode="ResponseRewrite"> </customErrors>
Protected Sub Page_Load(sender As Object, e As EventArgs) Handles Me.Load Dim rpt As New UnboundDSInvoice() Me.WebViewer1.Report = New UnboundDSInvoice() End Sub
In this case, we create a new Object our our Report, Run the Report, and Bind it to the viewer. In order to handle any errors caused by this we need to add some Try, Catch, and Finally statements around that code. See below:
Protected Sub Page_Load(sender As Object, e As EventArgs) Handles Me.Load Dim rpt As New UnboundDSInvoice() Try rpt.Run() Catch ex As Exception Throw New Exception(ex.Message & "This is an unhandled exception FROM ME.") Finally Me.WebViewer1.Report = New UnboundDSInvoice() End Try End Sub
This way, any errors that are thrown by ActiveReports will be caught in _ex_ as an exception and logged on the server. If an error is caught, the website will look into the web.config and redirect the user to the customError handler re-direct. We can stop here if we only want to abstract the error away from the user. If we want to catch the error and display it on the new page or write the error to a file on disk or email a error report out, we need to add some code to the Oops.aspx.cs file ( the code behind for the Oops.asmx page ).
So basically what is going on here, is that we grab the LastError off the server and check to make sure it's not null. We return the string back to the Page_Load. This is where you as a developer can customize what you do with the error. In my code above, I insert the string into the page for debugging purposes, you can replace that code with a File.IO write or an email send function. ar8_website_1_subreport_code