SSRS does not provide any facilities to step through the embedded code, and, thus, you have two options: You can either debug code in Visual Studio .NET or use some preVisual Basic tricks for debugging. The first trick is to label code lines. This is beneficial to locate both compile-time and runtime errors. The following code fragment shows how to label code lines. It also has errors that have been intentionally placed for demonstration purposes. Function Add(n As Integer) 1: i = i + n 2: return i End Function When you build a report with the code snippet or try to preview the report that calls this code, SSRS reports two issues (one warning and one error):
With a small code fragment such as the preceding example, finding errors might not be an issue. For a code fragment that has a significant number of lines, locating the one with an error can be a burden . Note Keep in mind that labels can only be present inside of functions or subroutines and can repeat inside of different functions. Tip To properly determine line numbers , deliberately add an error and preview the report. The SSRS error indicates the line number. Tip To avoid laborious efforts of numbering and renumbering of lines, you should only label key expressions or the first line of functions. Alternatively, you can use labeling to narrow down a line with an error. The second trick is to locate a line that causes runtime errors by using a trY-CATCH block: Function DivByZero() Dim x As Integer Try ' Set up structured error handling. 3: x = x/ 0 Catch ex As Exception Return ex.ToString() & vbCrLf & "Exception at Line: " & CStr(Erl) End Try End Function The result of the call to the function DivByZero() is System.OverflowException: Arithmetic operation resulted in an overflow. at ReportExprHostImpl.CustomCodeProxy.DivByZero() Exception at Line: 3 Note that function DivByZero() uses the undocumented function Erl to return a line number for the line of code that produced the error. Erl really returns a label number (in the preceding code, it is 3 ). When you do not implement error handling, and then make a call to a function within the Value property of a report item, the report item shows " #Error " as a result. Depending on the precision of a return value provided from a function, other potential results are " Infinity " or " NaN "(Not a Number). Tip Always check the Error List window after a Build operation has completed, and make sure that there are no warnings. Best practice suggests eliminating all warnings in production code. Exceptions within other properties can be caught during the Build operation. |