try-catch and using statements in exception handling

[bitm0de]

It says, "Use a try-catch statement for most exception handling" and proceeds to show an example where the exception could be avoided by doing bounds checks. I don't think this should be a recommended coding convention since exception-based programming is more expensive than mitigating exceptions that can be prevented.

If anything, this should demonstrate catching an exception that you can't prevent (i.e. SocketException in some cases), and not catching the System.Exception type but the most relevant derived exception as a best practice.

---

Document Details

⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

• ID: 40f42506-f4a5-859a-0266-ded002056d83
• Version Independent ID: f940f2ad-e13d-4d37-6439-f8afcbc4e4c7
• Content: C# Coding Conventions
• Content Source: docs/csharp/fundamentals/coding-style/coding-conventions.md
• Product: dotnet-csharp
• Technology: csharp-fundamentals
• GitHub Login: @BillWagner
• Microsoft Alias: wiwagn

---

Associated WorkItem - 123090

[BillWagner]

These are generally good suggestions @bitm0de

I'm not convinced that SocketException or something similar is the best option. I'd rather pick something more common, to avoid the need to explain more about the conditions which cause the exception.

[bitm0de]

These are generally good suggestions @bitm0de

I'm not convinced that SocketException or something similar is the best option. I'd rather pick something more common, to avoid the need to explain more about the conditions which cause the exception.

You mention that it is not the best option, although no alternative suggestion is made. SocketException is rather common in networking, and an exhaustive list of preconditions doesn't have to be provided to make a point. One probable cause is to state the closing of the connection from the server side. The real point being, to use a try-catch as the solution in an appropriate context for catching the exception (i.e. when you can't mitigate it in most circumstances).

The current example provides no explanation about what would cause an IndexOutOfRangeException, or whether it's the most appropriate way to handle the underlying cause of the exception rather than preventing it. Thus, it does seem odd to suggest the need for listing the causes for a SocketException, even if it is arguably a better use of a try-catch.