Remove unecessary try..catch constructs

[Mackiovello]

Fixes dotnet/docs#6271

[Mackiovello]

I decided to not do anything about the wonky spacing and indenting in many of these files. That should make it easier to review.

[Mackiovello]

I decided to always remove the try..catch constructs since they always just swallowed the exception and wrote to the console. There are very few cases where that's a good practice.

[BillWagner]

@Mackiovello I know this is aging a bit.

I'm having some internal discussions about what's the best plan here, because our sample code is used as a learning tool. Sometimes that means we use different practices than we would recommend for a production code base. We'll comment / review formally soon.

[rpetrusha]

Thanks for submitting another PR, @Mackiovello, and for eliminating some of the inappropriate exception handling from our examples. There are a few problems with simply removing exception handling, though. Our examples should handle exceptions that are likely to be thrown in the context of the example; they just shouldn't use Exception or SystemException to do that. In the case of the first example, exception handling should be used where there's user input. In the case of the last exception, one of the Add method calls is expected to fail; that should be handled as well. (I also can't get one of the examples to not throw an exception except by retrieving a union of identical URLs. But since the example isn't used in dotnet/docs or dotnet/dotnet-api-docs, that method can be removed.)

I've left comments for changes to be made in one C++ example and two C# examples; the comments apply, though, to all three sets of examples.

Again, thanks for doing this. We really appreciate it.

[rpetrusha]

The problem here, especially since Process.GetProcessesByName is passed user input, is that the string is unpredictable and remoteMachineName can cause a number of exceptions to be thrown. You can eliminate the ArgumentNullException by testing for a null or empty string before calling GetProcessesByName, but this as well as the C# and VB examples should still handle ArgumentException for an invalid remote computer name, and InvalidOperationException (for failure to connect to a remote computer -- an exception condition that isn't documented) at a minimum.

In general, while we certainly don't want to handle Exception and SystemException, we do want to handle exceptions that can realistically be thrown by an example.

[rpetrusha]

This is throwing a NotSupportedException. Despite the documentation, this seems to only succeed if given two equal URLs. At the same time, the functionality is not supported in .NET Framework 4 and later. But the example is not used. The UnionDemo method can be removed from the source code (and the call to UnionDemo on line 12 should also be removed).

[rpetrusha]

Since the container doesn't support duplicates, we can't simply not handle exceptions. The problem here is that line 184 throws a SystemException, which is inappropriate. You could change it to ArgumentException, then handle the ArgumentException in a try/catch block around all of the BookComponent instantiates and calls to the Add method.

[Mackiovello]

Thank you so much for the detailed feedback @rpetrusha!

I'll go through the examples over the next couple of days and ping you when I'm done.

I'm not quite sure how the project files are structured. For some examples, there's a project file in the same directory, but for others, there doesn't seem to be one. For example, for the GetProcessByName, I had to add my own project file in order to build and run. How is it supposed to work?

Also, I'm not super familiar with VB and C++, so please be extra observant that I'm following best practices with those languages.

[Mackiovello]

Checklist for myself:

GetProcessByName

• VB
• C#
• C++

UrlIdentity

• VB
• C#
• C++

LibraryContainer

• VB
• C#
• C++

[rpetrusha]

Thanks for responding, @Mackiovello. It's nice to be working with you again.

Since most of this is legacy code (almost all of the examples that handle Exception, and all of the example that handle SystemException, were written for .NET Framework 1.0 or 1.1), the examples were tested and run using the command-line compiler only. (In fact, when the examples were created, MSBuild didn't exist.) They can still be run using csc.exe.

Since our C++/CLI coverage tends to be spotty, we can simply plan on removing the C++ examples from the documentation if you don't feel comfortable modifying them. If you have difficulty with any of the VB examples, I can do them.

[Mackiovello]

Since our C++/CLI coverage tends to be spotty, we can simply plan on removing the C++ examples from the documentation if you don't feel comfortable modifying them.

I could modify the C++ examples, but I don't have an environment setup for it so it would take some extra time. Should I create an issue to remove them or remove them in this PR?

[rpetrusha]

You can just remove them in this PR, @Mackiovello. We want to leave existing C++ examples that don't require modification.

[Mackiovello]

@rpetrusha I've taken care of all the things you mentioned. Can you take another look?

[rpetrusha]

Thank you so much, @Mackiovello, both for submitting the PR and for all of the additional changes you've made. This looks really good, so I'll merge your PR now.