Bắt nhiều ngoại lệ cùng một lúc?

Nó được khuyến khích để chỉ đơn giản là bắt System.Exception. Thay vào đó, chỉ nên bắt những ngoại lệ "đã biết".

Bây giờ, điều này đôi khi dẫn đến mã lặp đi lặp lại không cần thiết, ví dụ:

try
{
    WebId = new Guid(queryString["web"]);
}
catch (FormatException)
{
    WebId = Guid.Empty;
}
catch (OverflowException)
{
    WebId = Guid.Empty;
}

Tôi tự hỏi: Có cách nào để bắt cả hai ngoại lệ và chỉ gọi WebId = Guid.Emptycuộc gọi một lần không?

Ví dụ đưa ra khá đơn giản, vì nó chỉ là a GUID. Nhưng hãy tưởng tượng mã nơi bạn sửa đổi một đối tượng nhiều lần và nếu một trong các thao tác thất bại theo cách dự kiến, bạn muốn "đặt lại" object. Tuy nhiên, nếu có một ngoại lệ bất ngờ, tôi vẫn muốn ném nó cao hơn.

Bắt System.Exceptionvà bật các loại

catch (Exception ex)            
{                
    if (ex is FormatException || ex is OverflowException)
    {
        WebId = Guid.Empty;
        return;
    }

    throw;
}

EDIT: Tôi đồng tình với những người khác đang nói rằng, kể từ C # 6.0, các bộ lọc ngoại lệ giờ đây là một cách hoàn toàn tốt để sử dụng:catch (Exception ex) when (ex is ... || ex is ... )

Ngoại trừ việc tôi vẫn ghét cách bố trí một dòng dài và cá nhân sẽ đặt mã ra như sau. Tôi nghĩ rằng đây là chức năng như nó là thẩm mỹ, vì tôi tin rằng nó cải thiện sự hiểu biết. Một số có thể không đồng ý:

catch (Exception ex) when (
    ex is ...
    || ex is ...
    || ex is ...
)

NGUYÊN:

Tôi biết tôi đến bữa tiệc muộn một chút, nhưng khói thánh ...

Cắt thẳng vào cuộc rượt đuổi, loại này trùng lặp một câu trả lời trước đó, nhưng nếu bạn thực sự muốn thực hiện một hành động chung cho một số loại ngoại lệ và giữ toàn bộ sự gọn gàng và gọn gàng trong phạm vi của một phương thức, tại sao không sử dụng lambda / đóng / chức năng nội tuyến để làm một cái gì đó như sau? Ý tôi là, rất có thể bạn sẽ nhận ra rằng bạn chỉ muốn biến việc đóng cửa đó thành một phương pháp riêng biệt mà bạn có thể sử dụng ở mọi nơi. Nhưng sau đó sẽ rất dễ dàng để làm điều đó mà không thực sự thay đổi phần còn lại của mã theo cấu trúc. Đúng?

private void TestMethod ()
{
    Action<Exception> errorHandler = ( ex ) => {
        // write to a log, whatever...
    };

    try
    {
        // try some stuff
    }
    catch ( FormatException  ex ) { errorHandler ( ex ); }
    catch ( OverflowException ex ) { errorHandler ( ex ); }
    catch ( ArgumentNullException ex ) { errorHandler ( ex ); }
}

Tôi không thể không tự hỏi ( cảnh báo: một chút mỉa mai / châm biếm phía trước) tại sao trên trái đất này phải nỗ lực hết sức để thay thế những điều sau đây:

try
{
    // try some stuff
}
catch( FormatException ex ){}
catch( OverflowException ex ){}
catch( ArgumentNullException ex ){}

... với một số biến thể điên rồ của mùi mã tiếp theo này, ý tôi là, chỉ để giả vờ rằng bạn đang lưu một vài tổ hợp phím.

// sorta sucks, let's be honest...
try
{
    // try some stuff
}
catch( Exception ex )
{
    if (ex is FormatException ||
        ex is OverflowException ||
        ex is ArgumentNullException)
    {
        // write to a log, whatever...
        return;
    }
    throw;
}

Bởi vì nó chắc chắn không tự động dễ đọc hơn.

Cấp, tôi để lại ba trường hợp giống hệt nhau trong /* write to a log, whatever... */ return;ví dụ đầu tiên.

Nhưng đó là loại quan điểm của tôi. Bạn đã nghe nói về các chức năng / phương thức, phải không? Nghiêm túc. Viết một ErrorHandlerhàm chung và, giống như, gọi nó từ mỗi khối bắt.

Nếu bạn hỏi tôi, ví dụ thứ hai (với các từ khóa ifvà iscả hai đều dễ đọc hơn đáng kể và đồng thời dễ bị lỗi hơn đáng kể trong giai đoạn bảo trì dự án của bạn.

Giai đoạn bảo trì, đối với bất kỳ ai có thể tương đối mới với lập trình, sẽ chiếm 98,7% hoặc hơn trong toàn bộ thời gian thực hiện dự án của bạn, và người nghèo khó thực hiện bảo trì gần như chắc chắn sẽ là một người khác ngoài bạn. Và có một cơ hội rất tốt họ sẽ dành 50% thời gian cho công việc chửi rủa tên bạn.

Và tất nhiên FxCop vỏ vào bạn và do đó bạn phải cũng thêm một thuộc tính để mã của bạn đã chính xác nén để làm với các chương trình đang chạy, và chỉ có nói với FxCop để bỏ qua một vấn đề mà trong 99,9% các trường hợp nó là hoàn toàn đúng trong việc gắn cờ. Và xin lỗi, tôi có thể nhầm, nhưng không phải thuộc tính "bỏ qua" đó thực sự được biên dịch vào ứng dụng của bạn sao?

Sẽ đặt toàn bộ ifbài kiểm tra trên một dòng làm cho nó dễ đọc hơn? Tôi không nghĩ vậy. Ý tôi là, tôi đã có một lập trình viên khác tranh cãi kịch liệt một thời gian dài trước đây rằng việc đặt nhiều mã trên một dòng sẽ làm cho nó "chạy nhanh hơn". Nhưng tất nhiên anh ấy đã ăn hạt dẻ. Cố gắng giải thích cho anh ta (với khuôn mặt thẳng thắn - đầy thách thức) làm thế nào trình thông dịch hoặc trình biên dịch sẽ chia dòng dài đó thành các câu lệnh một dòng riêng biệt - về cơ bản giống với kết quả nếu anh ta đi trước và chỉ làm cho mã có thể đọc được thay vì cố gắng thông minh trình biên dịch - không có tác dụng gì với anh ta. Nhưng tôi lạc đề.

Điều này có thể đọc được ít hơn bao nhiêu khi bạn thêm ba loại ngoại lệ, một hoặc hai tháng kể từ bây giờ? (Trả lời: nó ít được đọc hơn nhiều ).

Một trong những điểm chính, thực sự, là hầu hết các điểm định dạng mã nguồn văn bản mà tất cả chúng ta đang xem mỗi ngày là làm cho nó thực sự, thực sự rõ ràng đối với những người khác những gì thực sự xảy ra khi mã chạy. Bởi vì trình biên dịch biến mã nguồn thành một thứ hoàn toàn khác và không quan tâm nhiều đến phong cách định dạng mã của bạn. Vì vậy, tất cả trên một dòng hoàn toàn hút, quá.

Chỉ cần nói ...

// super sucks...
catch( Exception ex )
{
    if ( ex is FormatException || ex is OverflowException || ex is ArgumentNullException )
    {
        // write to a log, whatever...
        return;
    }
    throw;
}

Như những người khác đã chỉ ra, bạn có thể có một iftuyên bố trong khối bắt của bạn để xác định điều gì đang xảy ra. C # 6 hỗ trợ Bộ lọc ngoại lệ, do đó, những điều sau đây sẽ hoạt động:

try { … }
catch (Exception e) when (MyFilter(e))
{
    …
}

Các MyFilterphương pháp sau đó có thể trông giống như thế này:

private bool MyFilter(Exception e)
{
  return e is ArgumentNullException || e is FormatException;
}

Ngoài ra, điều này có thể được thực hiện tất cả nội tuyến (phía bên phải của câu lệnh khi chỉ phải là một biểu thức boolean).

try { … }
catch (Exception e) when (e is ArgumentNullException || e is FormatException)
{
    …
}

Điều này khác với việc sử dụng một ifcâu lệnh từ trong catchkhối, sử dụng các bộ lọc ngoại lệ sẽ không làm mất ngăn xếp.

Bạn có thể tải xuống Visual Studio 2015 để kiểm tra điều này.

Nếu bạn muốn tiếp tục sử dụng Visual Studio 2013, bạn có thể cài đặt gói nuget sau:

Cài đặt-Gói Microsoft.Net.Compilers

Tại thời điểm viết, điều này sẽ bao gồm hỗ trợ cho C # 6.

Tham chiếu gói này sẽ khiến dự án được xây dựng bằng phiên bản cụ thể của trình biên dịch C # và Visual Basic có trong gói, trái ngược với bất kỳ phiên bản nào được cài đặt hệ thống.

Thật không may trong C #, vì bạn cần một bộ lọc ngoại lệ để làm điều đó và C # không phơi bày tính năng đó của MSIL. VB.NET có khả năng này, vd

Catch ex As Exception When TypeOf ex Is FormatException OrElse TypeOf ex Is OverflowException

Những gì bạn có thể làm là sử dụng một hàm ẩn danh để đóng gói mã lỗi của mình và sau đó gọi nó trong các khối bắt cụ thể đó:

Action onError = () => WebId = Guid.Empty;
try
{
    // something
}
catch (FormatException)
{
    onError();
}
catch (OverflowException)
{
    onError();
}

Để hoàn thiện, vì .NET 4.0 , mã có thể được viết lại thành:

Guid.TryParse(queryString["web"], out WebId);

TryPude không bao giờ ném ngoại lệ và trả về false nếu định dạng sai, đặt WebId thành Guid.Empty.

Vì C # 7, bạn có thể tránh giới thiệu một biến trên một dòng riêng biệt:

Guid.TryParse(queryString["web"], out Guid webId);

Bạn cũng có thể tạo các phương thức để phân tích cú pháp trả về các bộ dữ liệu không có trong .NET Framework kể từ phiên bản 4.6:

(bool success, Guid result) TryParseGuid(string input) =>
    (Guid.TryParse(input, out Guid result), result);

Và sử dụng chúng như thế này:

WebId = TryParseGuid(queryString["web"]).result;
// or
var tuple = TryParseGuid(queryString["web"]);
WebId = tuple.success ? tuple.result : DefaultWebId;

Cập nhật vô ích tiếp theo cho câu trả lời vô dụng này xuất hiện khi việc giải cấu trúc các tham số ngoài được thực hiện trong C # 12. :)

Bộ lọc ngoại lệ hiện có sẵn trong c # 6+. Bạn có thể làm

try
{
       WebId = new Guid(queryString["web"]);
}
catch (Exception ex) when(ex is FormatException || ex is OverflowException)
{
     WebId = Guid.Empty;
}

Trong C # 7.0+, bạn cũng có thể kết hợp điều này với khớp mẫu

try
{
   await Task.WaitAll(tasks);
}
catch (Exception ex) when( ex is AggregateException ae &&
                           ae.InnerExceptions.Count > tasks.Count/2)
{
   //More than half of the tasks failed maybe..? 
}

Nếu bạn có thể nâng cấp ứng dụng của mình lên C # 6, bạn thật may mắn. Phiên bản C # mới đã triển khai các bộ lọc Ngoại lệ. Vì vậy, bạn có thể viết này:

catch (Exception ex) when (ex is FormatException || ex is OverflowException) {
    WebId = Guid.Empty;
}

Một số người nghĩ rằng mã này giống như

catch (Exception ex) {                
    if (ex is FormatException || ex is OverflowException) {
        WebId = Guid.Empty;
    }
    throw;
}

Nhưng nó không phải là. Trên thực tế đây là tính năng mới duy nhất trong C # 6 không thể mô phỏng trong các phiên bản trước. Đầu tiên, ném lại có nghĩa là nhiều chi phí hơn là bỏ qua việc bắt. Thứ hai, nó không tương đương về mặt ngữ nghĩa. Tính năng mới bảo vệ ngăn xếp nguyên vẹn khi bạn gỡ lỗi mã của mình. Không có tính năng này, kết xuất sự cố sẽ ít hữu ích hơn hoặc thậm chí vô dụng.

Xem một cuộc thảo luận về điều này trên CodePlex . Và một ví dụ cho thấy sự khác biệt .

Nếu bạn không muốn sử dụng một iftuyên bố trong catchphạm vi, trong C# 6.0bạn có thể sử dụng Exception Filterscú pháp mà đã được hỗ trợ bởi CLR trong các phiên bản xem trước nhưng chỉ tồn tại trong VB.NET/ MSIL:

try
{
    WebId = new Guid(queryString["web"]);
}
catch (Exception exception) when (exception is FormatException || ex is OverflowException)
{
    WebId = Guid.Empty;
}

Mã này sẽ chỉ bắt Exceptionkhi nó là một InvalidDataExceptionhoặc ArgumentNullException.

Trên thực tế, bạn có thể đặt bất kỳ điều kiện nào bên trong whenmệnh đề đó :

static int a = 8;

...

catch (Exception exception) when (exception is InvalidDataException && a == 8)
{
    Console.WriteLine("Catch");
}

Lưu ý rằng trái ngược với một iftuyên bố trong catchphạm vi của phạm vi, Exception Filterskhông thể ném Exceptionsvà khi chúng thực hiện hoặc khi điều kiện không xảy ra true, catchđiều kiện tiếp theo sẽ được đánh giá thay thế:

static int a = 7;

static int b = 0;

...

try
{
    throw new InvalidDataException();
}
catch (Exception exception) when (exception is InvalidDataException && a / b == 2)
{
    Console.WriteLine("Catch");
}
catch (Exception exception) when (exception is InvalidDataException || exception is ArgumentException)
{
    Console.WriteLine("General catch");
}

Đầu ra: Bắt chung.

Khi có nhiều thì một true Exception Filter- cái đầu tiên sẽ được chấp nhận:

static int a = 8;

static int b = 4;

...

try
{
    throw new InvalidDataException();
}
catch (Exception exception) when (exception is InvalidDataException && a / b == 2)
{
    Console.WriteLine("Catch");
}
catch (Exception exception) when (exception is InvalidDataException || exception is ArgumentException)
{
    Console.WriteLine("General catch");
}

Đầu ra: Bắt.

Và như bạn có thể thấy trong MSILmã không được dịch thành các ifcâu lệnh, nhưng Filters, và Exceptionskhông thể được ném từ bên trong các khu vực được đánh dấu Filter 1và thay vào đó, Filter 2bộ lọc ném di Exceptionchúc sẽ thất bại, cũng là giá trị so sánh cuối cùng được đẩy vào ngăn xếp trước endfilterlệnh sẽ xác định thành công / thất bại của bộ lọc ( Catch 1 XOR Catch 2 sẽ thực thi tương ứng):

Ngoài ra, đặc biệt Guidcó Guid.TryParsephương pháp.

Với C # 7 , câu trả lời từ Michael Stum có thể được cải thiện trong khi vẫn giữ được tính dễ đọc của câu lệnh chuyển đổi:

catch (Exception ex)
{
    switch (ex)
    {
        case FormatException _:
        case OverflowException _:
            WebId = Guid.Empty;
            break;
        default:
            throw;
    }
}

Và với C # 8 là biểu thức chuyển đổi:

catch (Exception ex)
{
    WebId = ex switch
    {
        _ when ex is FormatException || ex is OverflowException => Guid.Empty,
        _ => throw ex
    };
}

Câu trả lời được chấp nhận có vẻ chấp nhận được, ngoại trừ CodeAnalysis / FxCop sẽ phàn nàn về thực tế rằng nó bắt một loại ngoại lệ chung.

Ngoài ra, có vẻ như toán tử "là" có thể làm giảm hiệu suất một chút.

CA1800: Đừng bỏ qua một cách không cần thiết để "xem xét việc kiểm tra kết quả của toán tử 'as'", nhưng nếu bạn làm điều đó, bạn sẽ viết nhiều mã hơn nếu bạn nắm bắt từng ngoại lệ riêng biệt.

Dù sao, đây là những gì tôi sẽ làm:

bool exThrown = false;

try
{
    // Something
}
catch (FormatException) {
    exThrown = true;
}
catch (OverflowException) {
    exThrown = true;
}

if (exThrown)
{
    // Something else
}

trong C # 6, cách tiếp cận được đề xuất là sử dụng Bộ lọc ngoại lệ, đây là một ví dụ:

 try
 {
      throw new OverflowException();
 }
 catch(Exception e ) when ((e is DivideByZeroException) || (e is OverflowException))
 {
       // this will execute iff e is DividedByZeroEx or OverflowEx
       Console.WriteLine("E");
 }

Đây là một biến thể của câu trả lời của Matt (tôi cảm thấy rằng điều này sạch hơn một chút) ... sử dụng một phương pháp:

public void TryCatch(...)
{
    try
    {
       // something
       return;
    }
    catch (FormatException) {}
    catch (OverflowException) {}

    WebId = Guid.Empty;
}

Bất kỳ trường hợp ngoại lệ nào khác sẽ được đưa ra và mã WebId = Guid.Empty;sẽ không bị tấn công. Nếu bạn không muốn các ngoại lệ khác làm sập chương trình của mình, chỉ cần thêm SAU hai lần bắt khác:

...
catch (Exception)
{
     // something, if anything
     return; // only need this if you follow the example I gave and put it all in a method
}

Câu trả lời của Joseph Daigle là một giải pháp tốt, nhưng tôi thấy cấu trúc sau đây gọn gàng hơn và ít bị lỗi hơn.

catch(Exception ex)
{   
    if (!(ex is SomeException || ex is OtherException)) throw;

    // Handle exception
}

Có một vài lợi thế của việc đảo ngược biểu thức:

• Một tuyên bố trở lại là không cần thiết
• Mã không được lồng
• Không có nguy cơ quên các câu lệnh 'ném' hoặc 'trả lại' mà trong giải pháp của Joseph được tách ra khỏi biểu thức.

Nó thậm chí có thể được nén thành một dòng duy nhất (mặc dù không đẹp lắm)

catch(Exception ex) { if (!(ex is SomeException || ex is OtherException)) throw;

    // Handle exception
}

Chỉnh sửa: Các bộ lọc ngoại lệ trong C # 6.0 sẽ thực hiện cú pháp một chút bụi và đi kèm với một số lợi ích khác đối với bất kỳ giải pháp hiện tại. (đáng chú ý nhất là để ngăn xếp không hề hấn gì)

Đây là cách giải quyết vấn đề tương tự bằng cú pháp C # 6.0:

catch(Exception ex) when (ex is SomeException || ex is OtherException)
{
    // Handle exception
}

@Micheal

Phiên bản sửa đổi một chút của mã của bạn:

catch (Exception ex)
{
   Type exType = ex.GetType();
   if (exType == typeof(System.FormatException) || 
       exType == typeof(System.OverflowException)
   {
       WebId = Guid.Empty;
   } else {
      throw;
   }
}

So sánh chuỗi là xấu xí và chậm.

Làm thế nào về

try
{
    WebId = Guid.Empty;
    WebId = new Guid(queryString["web"]);
}
catch (FormatException)
{
}
catch (OverflowException)
{
}

catch (Exception ex)
{
    if (!(
        ex is FormatException ||
        ex is OverflowException))
    {
        throw;
    }
    Console.WriteLine("Hello");
}

Thận trọng và cảnh báo: Một loại khác, phong cách chức năng.

Những gì trong liên kết không trả lời trực tiếp câu hỏi của bạn, nhưng thật tầm thường khi mở rộng nó thành:

static void Main() 
{ 
    Action body = () => { ...your code... };

    body.Catch<InvalidOperationException>() 
        .Catch<BadCodeException>() 
        .Catch<AnotherException>(ex => { ...handler... })(); 
}

(Về cơ bản cung cấp một Catchquá tải trống khác mà trả về chính nó)

Câu hỏi lớn hơn cho vấn đề này là tại sao . Tôi không nghĩ rằng chi phí vượt xa mức tăng ở đây :)

Cập nhật 2015-12-15: Xem https://stackoverflow.com/a/22864936/1718702 cho C # 6. Đó là một trình dọn dẹp và bây giờ là tiêu chuẩn trong ngôn ngữ.

Dành cho những người muốn có một giải pháp thanh lịch hơn để bắt một lần và lọc các ngoại lệ, tôi sử dụng một phương pháp mở rộng như được trình bày dưới đây.

Tôi đã có phần mở rộng này trong thư viện của mình, ban đầu được viết cho các mục đích khác, nhưng nó hoạt động hoàn hảo để typekiểm tra các ngoại lệ. Thêm vào đó, imho, nó trông sạch sẽ hơn một loạt các ||tuyên bố. Ngoài ra, không giống như câu trả lời được chấp nhận, tôi thích xử lý ngoại lệ rõ ràng vì vậy ex is ...có hành vi không thể chấp nhận được vì các lớp bị loại bỏ được gán cho các kiểu cha mẹ).

Sử dụng

if (ex.GetType().IsAnyOf(
    typeof(FormatException),
    typeof(ArgumentException)))
{
    // Handle
}
else
    throw;

Tiện ích mở rộng IsAnyOf.cs (Xem ví dụ xử lý lỗi đầy đủ cho các phụ thuộc)

namespace Common.FluentValidation
{
    public static partial class Validate
    {
        /// <summary>
        /// Validates the passed in parameter matches at least one of the passed in comparisons.
        /// </summary>
        /// <typeparam name="T"></typeparam>
        /// <param name="p_parameter">Parameter to validate.</param>
        /// <param name="p_comparisons">Values to compare against.</param>
        /// <returns>True if a match is found.</returns>
        /// <exception cref="ArgumentNullException"></exception>
        public static bool IsAnyOf<T>(this T p_parameter, params T[] p_comparisons)
        {
            // Validate
            p_parameter
                .CannotBeNull("p_parameter");
            p_comparisons
                .CannotBeNullOrEmpty("p_comparisons");

            // Test for any match
            foreach (var item in p_comparisons)
                if (p_parameter.Equals(item))
                    return true;

            // Return no matches found
            return false;
        }
    }
}

Ví dụ xử lý lỗi đầy đủ (Sao chép-Dán vào ứng dụng Bảng điều khiển mới)

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Common.FluentValidation;

namespace IsAnyOfExceptionHandlerSample
{
    class Program
    {
        static void Main(string[] args)
        {
            // High Level Error Handler (Log and Crash App)
            try
            {
                Foo();
            }
            catch (OutOfMemoryException ex)
            {
                Console.WriteLine("FATAL ERROR! System Crashing. " + ex.Message);
                Console.ReadKey();
            }
        }

        static void Foo()
        {
            // Init
            List<Action<string>> TestActions = new List<Action<string>>()
            {
                (key) => { throw new FormatException(); },
                (key) => { throw new ArgumentException(); },
                (key) => { throw new KeyNotFoundException();},
                (key) => { throw new OutOfMemoryException(); },
            };

            // Run
            foreach (var FooAction in TestActions)
            {
                // Mid-Level Error Handler (Appends Data for Log)
                try
                {
                    // Init
                    var SomeKeyPassedToFoo = "FooParam";

                    // Low-Level Handler (Handle/Log and Keep going)
                    try
                    {
                        FooAction(SomeKeyPassedToFoo);
                    }
                    catch (Exception ex)
                    {
                        if (ex.GetType().IsAnyOf(
                            typeof(FormatException),
                            typeof(ArgumentException)))
                        {
                            // Handle
                            Console.WriteLine("ex was {0}", ex.GetType().Name);
                            Console.ReadKey();
                        }
                        else
                        {
                            // Add some Debug info
                            ex.Data.Add("SomeKeyPassedToFoo", SomeKeyPassedToFoo.ToString());
                            throw;
                        }
                    }
                }
                catch (KeyNotFoundException ex)
                {
                    // Handle differently
                    Console.WriteLine(ex.Message);

                    int Count = 0;
                    if (!Validate.IsAnyNull(ex, ex.Data, ex.Data.Keys))
                        foreach (var Key in ex.Data.Keys)
                            Console.WriteLine(
                                "[{0}][\"{1}\" = {2}]",
                                Count, Key, ex.Data[Key]);

                    Console.ReadKey();
                }
            }
        }
    }
}

namespace Common.FluentValidation
{
    public static partial class Validate
    {
        /// <summary>
        /// Validates the passed in parameter matches at least one of the passed in comparisons.
        /// </summary>
        /// <typeparam name="T"></typeparam>
        /// <param name="p_parameter">Parameter to validate.</param>
        /// <param name="p_comparisons">Values to compare against.</param>
        /// <returns>True if a match is found.</returns>
        /// <exception cref="ArgumentNullException"></exception>
        public static bool IsAnyOf<T>(this T p_parameter, params T[] p_comparisons)
        {
            // Validate
            p_parameter
                .CannotBeNull("p_parameter");
            p_comparisons
                .CannotBeNullOrEmpty("p_comparisons");

            // Test for any match
            foreach (var item in p_comparisons)
                if (p_parameter.Equals(item))
                    return true;

            // Return no matches found
            return false;
        }

        /// <summary>
        /// Validates if any passed in parameter is equal to null.
        /// </summary>
        /// <param name="p_parameters">Parameters to test for Null.</param>
        /// <returns>True if one or more parameters are null.</returns>
        public static bool IsAnyNull(params object[] p_parameters)
        {
            p_parameters
                .CannotBeNullOrEmpty("p_parameters");

            foreach (var item in p_parameters)
                if (item == null)
                    return true;

            return false;
        }
    }
}

namespace Common.FluentValidation
{
    public static partial class Validate
    {
        /// <summary>
        /// Validates the passed in parameter is not null, throwing a detailed exception message if the test fails.
        /// </summary>
        /// <param name="p_parameter">Parameter to validate.</param>
        /// <param name="p_name">Name of tested parameter to assist with debugging.</param>
        /// <exception cref="ArgumentNullException"></exception>
        public static void CannotBeNull(this object p_parameter, string p_name)
        {
            if (p_parameter == null)
                throw
                    new
                        ArgumentNullException(
                        string.Format("Parameter \"{0}\" cannot be null.",
                        p_name), default(Exception));
        }
    }
}

namespace Common.FluentValidation
{
    public static partial class Validate
    {
        /// <summary>
        /// Validates the passed in parameter is not null or an empty collection, throwing a detailed exception message if the test fails.
        /// </summary>
        /// <typeparam name="T"></typeparam>
        /// <param name="p_parameter">Parameter to validate.</param>
        /// <param name="p_name">Name of tested parameter to assist with debugging.</param>
        /// <exception cref="ArgumentNullException"></exception>
        /// <exception cref="ArgumentOutOfRangeException"></exception>
        public static void CannotBeNullOrEmpty<T>(this ICollection<T> p_parameter, string p_name)
        {
            if (p_parameter == null)
                throw new ArgumentNullException("Collection cannot be null.\r\nParameter_Name: " + p_name, default(Exception));

            if (p_parameter.Count <= 0)
                throw new ArgumentOutOfRangeException("Collection cannot be empty.\r\nParameter_Name: " + p_name, default(Exception));
        }

        /// <summary>
        /// Validates the passed in parameter is not null or empty, throwing a detailed exception message if the test fails.
        /// </summary>
        /// <param name="p_parameter">Parameter to validate.</param>
        /// <param name="p_name">Name of tested parameter to assist with debugging.</param>
        /// <exception cref="ArgumentException"></exception>
        public static void CannotBeNullOrEmpty(this string p_parameter, string p_name)
        {
            if (string.IsNullOrEmpty(p_parameter))
                throw new ArgumentException("String cannot be null or empty.\r\nParameter_Name: " + p_name, default(Exception));
        }
    }
}

Hai bài kiểm tra đơn vị NUnit mẫu

Kết hợp hành vi cho Exceptioncác loại là chính xác (ví dụ: Một đứa trẻ KHÔNG phải là đối sánh cho bất kỳ loại cha mẹ nào của nó).

using System;
using System.Collections.Generic;
using Common.FluentValidation;
using NUnit.Framework;

namespace UnitTests.Common.Fluent_Validations
{
    [TestFixture]
    public class IsAnyOf_Tests
    {
        [Test, ExpectedException(typeof(ArgumentNullException))]
        public void IsAnyOf_ArgumentNullException_ShouldNotMatch_ArgumentException_Test()
        {
            Action TestMethod = () => { throw new ArgumentNullException(); };

            try
            {
                TestMethod();
            }
            catch (Exception ex)
            {
                if (ex.GetType().IsAnyOf(
                    typeof(ArgumentException), /*Note: ArgumentNullException derrived from ArgumentException*/
                    typeof(FormatException),
                    typeof(KeyNotFoundException)))
                {
                    // Handle expected Exceptions
                    return;
                }

                //else throw original
                throw;
            }
        }

        [Test, ExpectedException(typeof(OutOfMemoryException))]
        public void IsAnyOf_OutOfMemoryException_ShouldMatch_OutOfMemoryException_Test()
        {
            Action TestMethod = () => { throw new OutOfMemoryException(); };

            try
            {
                TestMethod();
            }
            catch (Exception ex)
            {
                if (ex.GetType().IsAnyOf(
                    typeof(OutOfMemoryException),
                    typeof(StackOverflowException)))
                    throw;

                /*else... Handle other exception types, typically by logging to file*/
            }
        }
    }
}

Vì tôi cảm thấy như những câu trả lời này vừa chạm vào bề mặt, tôi đã cố gắng đào sâu hơn một chút.

Vì vậy, những gì chúng ta thực sự muốn làm là một cái gì đó không biên dịch, nói:

// Won't compile... damn
public static void Main()
{
    try
    {
        throw new ArgumentOutOfRangeException();
    }
    catch (ArgumentOutOfRangeException)
    catch (IndexOutOfRangeException) 
    {
        // ... handle
    }

Lý do chúng tôi muốn điều này là vì chúng tôi không muốn người xử lý ngoại lệ nắm bắt những thứ mà chúng tôi cần sau này trong quy trình. Chắc chắn, chúng ta có thể bắt Ngoại lệ và kiểm tra 'nếu' phải làm gì, nhưng hãy trung thực, chúng ta không thực sự muốn điều đó. (FxCop, vấn đề gỡ lỗi, xấu xí)

Vậy tại sao mã này không được biên dịch - và làm thế nào chúng ta có thể hack nó theo cách mà nó sẽ?

Nếu chúng ta nhìn vào mã, những gì chúng ta thực sự muốn làm là chuyển tiếp cuộc gọi. Tuy nhiên, theo Phân vùng MS II, các khối xử lý ngoại lệ IL sẽ không hoạt động như thế này, trong trường hợp này có ý nghĩa vì điều đó có nghĩa là đối tượng 'ngoại lệ' có thể có các loại khác nhau.

Hoặc để viết nó bằng mã, chúng tôi yêu cầu trình biên dịch làm một cái gì đó như thế này (nó không hoàn toàn chính xác, nhưng đó là điều gần nhất có thể tôi đoán):

// Won't compile... damn
try
{
    throw new ArgumentOutOfRangeException();
}
catch (ArgumentOutOfRangeException e) {
    goto theOtherHandler;
}
catch (IndexOutOfRangeException e) {
theOtherHandler:
    Console.WriteLine("Handle!");
}

Lý do mà điều này sẽ không được biên dịch là khá rõ ràng: đối tượng '$ ngoại lệ' sẽ có loại (giá trị nào được lưu trữ trong các biến 'e')? Cách chúng tôi muốn trình biên dịch xử lý việc này là lưu ý rằng loại cơ sở chung của cả hai ngoại lệ là 'Ngoại lệ', sử dụng biến đó để chứa cả hai ngoại lệ và sau đó chỉ xử lý hai ngoại lệ được bắt. Cách thức này được triển khai trong IL là 'bộ lọc', có sẵn trong VB.Net.

Để làm cho nó hoạt động trong C #, chúng ta cần một biến tạm thời với loại cơ sở 'Ngoại lệ' chính xác. Để kiểm soát luồng mã, chúng ta có thể thêm một số nhánh. Đây là:

    Exception ex;
    try
    {
        throw new ArgumentException(); // for demo purposes; won't be caught.
        goto noCatch;
    }
    catch (ArgumentOutOfRangeException e) {
        ex = e;
    }
    catch (IndexOutOfRangeException e) {
        ex = e;
    }

    Console.WriteLine("Handle the exception 'ex' here :-)");
    // throw ex ?

noCatch:
    Console.WriteLine("We're done with the exception handling.");

Nhược điểm rõ ràng cho điều này là chúng ta không thể ném lại đúng cách, và - hãy trung thực - rằng đó là giải pháp khá xấu xí. Sự xấu xí có thể được khắc phục một chút bằng cách thực hiện loại bỏ nhánh, điều này làm cho giải pháp tốt hơn một chút:

Exception ex = null;
try
{
    throw new ArgumentException();
}
catch (ArgumentOutOfRangeException e)
{
    ex = e;
}
catch (IndexOutOfRangeException e)
{
    ex = e;
}
if (ex != null)
{
    Console.WriteLine("Handle the exception here :-)");
}

Điều đó chỉ để lại 'ném lại'. Để làm việc này, chúng ta cần có khả năng thực hiện việc xử lý bên trong khối 'bắt' - và cách duy nhất để thực hiện công việc này là bằng một đối tượng bắt 'Ngoại lệ'.

Tại thời điểm này, chúng ta có thể thêm một chức năng riêng biệt xử lý các loại Ngoại lệ khác nhau bằng cách sử dụng độ phân giải quá tải hoặc để xử lý Ngoại lệ. Cả hai đều có nhược điểm. Để bắt đầu, đây là cách thực hiện với chức năng trợ giúp:

private static bool Handle(Exception e)
{
    Console.WriteLine("Handle the exception here :-)");
    return true; // false will re-throw;
}

public static void Main()
{
    try
    {
        throw new OutOfMemoryException();
    }
    catch (ArgumentException e)
    {
        if (!Handle(e)) { throw; }
    }
    catch (IndexOutOfRangeException e)
    {
        if (!Handle(e)) { throw; }
    }

    Console.WriteLine("We're done with the exception handling.");

Và giải pháp khác là bắt đối tượng Exception và xử lý nó cho phù hợp. Bản dịch theo nghĩa đen nhất cho điều này, dựa trên bối cảnh ở trên là đây:

try
{
    throw new ArgumentException();
}
catch (Exception e)
{
    Exception ex = (Exception)(e as ArgumentException) ?? (e as IndexOutOfRangeException);
    if (ex != null)
    {
        Console.WriteLine("Handle the exception here :-)");
        // throw ?
    }
    else 
    {
        throw;
    }
}

Vì vậy, để kết luận:

• Nếu chúng tôi không muốn ném lại, chúng tôi có thể xem xét nắm bắt các ngoại lệ phù hợp và lưu trữ chúng tạm thời.
• Nếu trình xử lý đơn giản và chúng tôi muốn sử dụng lại mã, giải pháp tốt nhất có lẽ là giới thiệu chức năng trợ giúp.
• Nếu chúng tôi muốn ném lại, chúng tôi không có lựa chọn nào khác ngoài việc đặt mã vào trình xử lý bắt 'Ngoại lệ', điều này sẽ phá vỡ FxCop và ngoại lệ của trình gỡ lỗi của bạn.

Đây là một vấn đề kinh điển mà mọi nhà phát triển C # phải đối mặt cuối cùng.

Hãy để tôi chia câu hỏi của bạn thành 2 câu hỏi. Đầu tiên,

Tôi có thể bắt được nhiều ngoại lệ cùng một lúc không?

Tóm lại, không.

Điều này dẫn đến câu hỏi tiếp theo,

Làm cách nào để tránh viết mã trùng lặp do tôi không thể bắt được nhiều loại ngoại lệ trong cùng một khối Catch ()?

Với mẫu cụ thể của bạn, trong đó giá trị dự phòng rẻ để xây dựng, tôi muốn làm theo các bước sau:

1. Khởi tạo WebId thành giá trị dự phòng.
2. Xây dựng một hướng dẫn mới trong một biến tạm thời.
3. Đặt WebId cho biến tạm thời được xây dựng đầy đủ. Đặt đây là tuyên bố cuối cùng của khối thử {}.

Vì vậy, mã trông như:

try
{
    WebId = Guid.Empty;
    Guid newGuid = new Guid(queryString["web"]);
    // More initialization code goes here like 
    // newGuid.x = y;
    WebId = newGuid;
}
catch (FormatException) {}
catch (OverflowException) {}

Nếu có bất kỳ ngoại lệ nào được đưa ra, thì WebId sẽ không bao giờ được đặt thành giá trị được xây dựng một nửa và vẫn là Guid.Empty.

Nếu việc xây dựng giá trị dự phòng là tốn kém và việc đặt lại một giá trị rẻ hơn nhiều, thì tôi sẽ chuyển mã đặt lại vào chức năng của chính nó:

try
{
    WebId = new Guid(queryString["web"]);
    // More initialization code goes here.
}
catch (FormatException) {
    Reset(WebId);
}
catch (OverflowException) {
    Reset(WebId);
}

Vì vậy, bạn có thể lặp lại rất nhiều mã trong mỗi chuyển đổi ngoại lệ không? Âm thanh như trích xuất một phương pháp sẽ là ý tưởng của chúa, phải không?

Vì vậy, mã của bạn đi xuống này:

MyClass instance;
try { instance = ... }
catch(Exception1 e) { Reset(instance); }
catch(Exception2 e) { Reset(instance); }
catch(Exception) { throw; }

void Reset(MyClass instance) { /* reset the state of the instance */ }

Tôi tự hỏi tại sao không ai nhận thấy rằng sao chép mã.

Từ C # 6, bạn cũng có các bộ lọc ngoại lệ như đã được đề cập bởi những người khác. Vì vậy, bạn có thể sửa đổi mã ở trên để này:

try { ... }
catch(Exception e) when(e is Exception1 || e is Exception2)
{ 
    Reset(instance); 
}

Muốn thêm câu trả lời ngắn của tôi cho chủ đề đã dài này. Một cái gì đó chưa được đề cập là thứ tự ưu tiên của các câu lệnh bắt, cụ thể hơn là bạn cần phải biết phạm vi của từng loại ngoại lệ bạn đang cố gắng nắm bắt.

Ví dụ: nếu bạn sử dụng ngoại lệ "bắt tất cả" như Ngoại lệ, nó sẽ đi trước tất cả các câu lệnh bắt khác và rõ ràng bạn sẽ gặp lỗi trình biên dịch, tuy nhiên nếu bạn đảo ngược thứ tự bạn có thể xâu chuỗi các câu lệnh bắt của bạn (tôi nghĩ là một mô hình chống ) bạn có thể đặt loại Ngoại lệ bắt tất cả ở dưới cùng và điều này sẽ nắm bắt bất kỳ trường hợp ngoại lệ nào không phục vụ cao hơn trong khối try..catch của bạn:

            try
            {
                // do some work here
            }
            catch (WebException ex)
            {
                // catch a web excpetion
            }
            catch (ArgumentException ex)
            {
                // do some stuff
            }
            catch (Exception ex)
            {
                // you should really surface your errors but this is for example only
                throw new Exception("An error occurred: " + ex.Message);
            }

Tôi đặc biệt khuyên mọi người nên xem lại tài liệu MSDN này:

Phân cấp ngoại lệ

Có thể cố gắng giữ cho mã của bạn đơn giản, chẳng hạn như đặt mã chung vào một phương thức, như bạn sẽ làm trong bất kỳ phần nào khác của mã không nằm trong mệnh đề bắt?

Ví dụ:

try
{
    // ...
}
catch (FormatException)
{
    DoSomething();
}
catch (OverflowException)
{
    DoSomething();
}

// ...

private void DoSomething()
{
    // ...
}

Làm thế nào tôi sẽ làm điều đó, cố gắng tìm đơn giản là mẫu đẹp

Lưu ý rằng tôi đã tìm thấy một cách để làm điều đó, nhưng điều này trông giống như tài liệu cho The Daily WTF :

catch (Exception ex)
{
    switch (ex.GetType().Name)
    {
        case "System.FormatException":
        case "System.OverflowException":
            WebId = Guid.Empty;
            break;
        default:
            throw;
    }
}

Điều đáng nói ở đây. Bạn có thể trả lời nhiều kết hợp (Lỗi ngoại lệ và ngoại lệ.message).

Tôi gặp phải một tình huống sử dụng khi cố gắng truyền đối tượng điều khiển trong một tệp dữ liệu, với nội dung là TextBox, TextBlock hoặc CheckBox. Trong trường hợp này, Ngoại lệ được trả về là như nhau, nhưng thông báo khác nhau.

try
{
 //do something
}
catch (Exception ex) when (ex.Message.Equals("the_error_message1_here"))
{
//do whatever you like
} 
catch (Exception ex) when (ex.Message.Equals("the_error_message2_here"))
{
//do whatever you like
} 

Tôi muốn đề xuất câu trả lời ngắn nhất (thêm một kiểu chức năng ):

        Catch<FormatException, OverflowException>(() =>
            {
                WebId = new Guid(queryString["web"]);
            },
            exception =>
            {
                WebId = Guid.Empty;
            });

Để làm điều này, bạn cần tạo một số quá tải phương thức "Catch", tương tự như System.Action:

    [DebuggerNonUserCode]
    public static void Catch<TException1, TException2>(Action tryBlock,
        Action<Exception> catchBlock)
    {
        CatchMany(tryBlock, catchBlock, typeof(TException1), typeof(TException2));
    }

    [DebuggerNonUserCode]
    public static void Catch<TException1, TException2, TException3>(Action tryBlock,
        Action<Exception> catchBlock)
    {
        CatchMany(tryBlock, catchBlock, typeof(TException1), typeof(TException2), typeof(TException3));
    }

và nhiều như bạn muốn. Nhưng bạn cần phải thực hiện một lần và bạn có thể sử dụng nó trong tất cả các dự án của bạn (hoặc, nếu bạn đã tạo gói nuget, chúng tôi cũng có thể sử dụng nó).

Và CatchMany thực hiện:

    [DebuggerNonUserCode]
    public static void CatchMany(Action tryBlock, Action<Exception> catchBlock,
        params Type[] exceptionTypes)
    {
        try
        {
            tryBlock();
        }
        catch (Exception exception)
        {
            if (exceptionTypes.Contains(exception.GetType())) catchBlock(exception);
            else throw;
        }
    }

ps Tôi chưa đặt kiểm tra null cho đơn giản mã, xem xét để thêm xác nhận tham số.

ps2 Nếu bạn muốn trả về một giá trị từ lệnh bắt, thì cần phải thực hiện các phương thức Catch tương tự, nhưng với trả về và Func thay vì Action trong các tham số.

Chỉ cần gọi thử và bắt hai lần.

try
{
    WebId = new Guid(queryString["web"]);
}
catch (FormatException)
{
    WebId = Guid.Empty;
}
try
{
    WebId = new Guid(queryString["web"]);
}
catch (OverflowException)
{
    WebId = Guid.Empty;
}

Nó chỉ đơn giản vậy thôi !!

Trong c # 6.0, Bộ lọc ngoại lệ là các cải tiến để xử lý ngoại lệ

try
{
    DoSomeHttpRequest();
}
catch (System.Web.HttpException e)
{
    switch (e.GetHttpCode())
    {
        case 400:
            WriteLine("Bad Request");
        case 500:
            WriteLine("Internal Server Error");
        default:
            WriteLine("Generic Error");
    }
}