Typically, if the code contains a Try…Catch block, the code will catch and rethrow all exceptions. That may not be the right choice for your project. For each exception, there are several ways to respond. Some possible actions:

• Add code to each Catch block for the action you choose.

• Do nothing, by removing the code that appears in the Catch block. This causes the application to ignore the error. It is unlikely that your application will recover gracefully if you take this approach.

• Get more input from the user to try to fix the condition.

• During execution of the Try block, undo any changes that were made to application data before the exception was thrown.

• Throw the exception back to the calling method.

• Throw an exception that you define for this application.

• Delete the Catch statement for that exception and let the calling method handle it. This is especially appropriate if the exception is not relevant to your task.

• Add additional Catch blocks to the code to catch specific types of exceptions that you want to handle.

• Add a Finally block to add code that you want to execute after the Try and Catch blocks.

If the code contains a string value, typically it is a specific string, such as "c:\filename.txt". This hard-coded string is useful for demonstration purposes, but unlikely to be the correct string for your application. Potential sources of strings in your application include:

• A string variable.

• A method or property that returns a string, such as the InputBox function.

• A string from a Windows Forms control, such as a TextBox or ComboBox.

Most file names in the code are shown as either being in My Documents or in c:\. When replacing the file locations, there are several considerations, including:

• Finding an accessible location. Users may not have access to the \Program Files folder of the computer, so storing files with the application files may not work.

• Finding a secure location. Storing files in the root folder (c:\) is not secure. For application data, we recommend the \Application Data folder. For individual user data, the application can create a file for each user in the \My Documents folder.

• Using a valid file name. You can use the OpenFileDialog Component (Windows Forms) and SaveFileDialog Component (Windows Forms) to reduce the likelihood of invalid file names. Be aware that between the time the user selects a file and the time your code manipulates the file, the file may be deleted. In addition, the user may not have permissions to write to the file.

Control and component names referenced in the code usually have a default designer name, such as Button1 or TreeView1. This emphasizes the type of control being shown, but it may not be a name you use in your application.

Some snippets only show an empty language structure, such as a Try…Catch block. Another common scenario is a validation variable, such as IsValid, that is set to True by default. The code provided will compile and run, but will not have any functionality. In these examples, you will need to add the code for your task.

How secure a snippet is depends on where it is used in the source code and how it is modified once it is in the code. The following list contains a few of the areas that must be considered.

• File and database access

• Code access security

• Protecting resources (such as event logs, registry)

• Storing secrets

• Verifying inputs

• Passing data to scripting technologies

For more information, see Security Considerations in Using Snippets and Securing Applications.

Tasks

Concepts

Reference