c# barcode image generation library IMPLEMENTING OBJECT COLLABORATION in Font

Printing DataMatrix in Font IMPLEMENTING OBJECT COLLABORATION

. . . Try sr = File.OpenText(strFilePath) strFileText = sr.ReadToEnd() sr.Close() Return strFileText Catch e As DirectoryNotFoundException Return e.Message Catch e As FileNotFoundException Return e.Message Catch Return "An unhandled error has occurred!" End Try . . .

Additionally, you can nest a Finally block at the end of the Try block. Unlike the Catch block, the use of the Finally block is optional. The Finally block is for any cleanup code that needs to occur, even if an exception is encountered. For example, you may need to close a database connection or release a file. When the code of the Try block is executed and an exception occurs, processing will jump to the appropriate Catch block. After the Catch block executes, the Finally block will execute. If the Try block executes and no exception is encountered, the Catch blocks do not execute, but the Finally block will still get processed. The following code shows a Finally block being used to close a connection to a SQL Server database: Public Sub MakeConnection() Dim myConnString As String Dim myConnection As SqlConnection = Nothing Try myConnString = "user id=sa;" & _ "password=;database=northwind;server=myserver" myConnection = New SqlConnection(myConnString) myConnection.Open() 'Code to interact with database . . . Catch myException As SqlException Dim myErrors As SqlErrorCollection = myException.Errors Dim i As Integer For i = 0 To myErrors.Count - 1 MessageBox.Show("Index #" & i & ControlChars.Cr & _ "Error: " & myErrors(i).ToString() & ControlChars.Cr) Next i Finally If myConnection IsNot Nothing Then myConnection.Close() End If End Try End Sub

During code execution, when an exception occurs that does not fit into one of the predefined system exception classes, you can throw your own exception. You normally throw your own exception when the error will not cause problems with execution, but rather with the processing of your business rules. For example, you could look for an order date that is in the future and throw an invalid date range exception. When you throw an exception, you are creating an instance of the System.Exception class. The following code shows an example of throwing a custom exception: Public Sub LogOrder(ByVal OrderNumber As Long, _ ByVal OrderDate As Date) Try If OrderDate > Now() Then Throw New Exception _ ("Order date cannot be in the future.") End If 'Processing code. . . Catch 'Exception handler code . . . End Try End Sub

In some cases, you may be able to correct an exception that occurred and continue processing the rest of the code in the Try block. For example, a division by zero error may occur, and it would be acceptable to assign the result a value of zero and continue processing. In this case, a Try-Catch block could be nested around the line of code that would cause the exception. After the exception is handled, processing would return to the line of code in the outer Try-Catch immediately after the nested Try block. The following code demonstrates nesting one Try block within another: Try Try Y1 = X1 / X2 Catch e As DivideByZeroException Y1 = 0 End Try 'Rest of processing code . . . Catch 'Outer exception processing . . . End Try

Note For more information about handling exceptions and the .NET Framework exception classes, refer

When you declare an object instance of a class, it instantiates its own instances of the properties and methods defined by the class. For example, if you had a counting routine that incremented a counter and you instantiated two object instances of the class, the counters of each object would be independent of each other. If you increment one counter, it would have no effect on the other counter. Normally, this object independence is the behavior you want. However, sometimes you may want different object instances of a class accessing shared variables. For example, you may want to build in a counter that logs how many of the object instances have been instantiated. In this case, you would create a shared property value in the class definition. The following code demonstrates how you create a shared TaxRate property in a class definition: Public Class AccountingUtilities Private Shared _TaxRate As Single = 0.06 Public Shared ReadOnly Property TaxRate() As Single Get Return _TaxRate End Get End Property End Class To access the shared property, you do not create an object instance of the class, but refer to the class directly. The following code shows a client accessing the shared TaxRate property defined previously: Public Class Purchase Public Function CalculateTax(ByVal PurchasePrice As Double) _ As Double Return PurchasePrice * AccountingUtilities.TaxRate End Function End Class Shared methods are useful if you have utility functions that clients need to access but do not want the overhead of creating an object instance of a class to gain access to the method. Note that shared methods can access only shared properties. The following code shows a shared method used to count the number of users currently logged in to an application: Public Class UserLog Private Shared _UserCount As Integer Public Shared Sub IncrementUserCount() _UserCount += 1 End Sub Public Shared Sub DecrementUserCount() _UserCount -= 1 End Sub End Class When client code accesses a shared method, it does so by referencing the class directly and does not need to create an object instance of the class. The following code demonstrates accessing the shared method defined previously: