2009-11-26 25 views
24

Tôi đã tạo ra ngoại lệ tùy chỉnh lớpXác định loại ngoại lệ trong một handler

public class Web2PDFException : Exception 
{ 
    public Web2PDFException(string message, 
     Exception innerException) 
     : base(message, innerException) 
    { 
    } 
} 

Trong ứng dụng của tôi, tôi muốn tìm hiểu là ngoại lệ ném là ngoại lệ tùy chỉnh của tôi hay không.

try 
{ 
} 
catch (Exception err) 
{ 
//Find exception type here 
} 

Trả lời

33

CẬP NHẬT: giả sử C# 6, cơ hội là trường hợp của bạn có thể được thể hiện dưới dạng bộ lọc ngoại lệ. Đây là phương pháp lý tưởng từ góc độ hiệu suất giả định yêu cầu của bạn có thể được thể hiện bằng thuật ngữ của nó, ví dụ:

try 
{ 
} 
catch (Web2PDFException ex) when (ex.Code == 52) 
{ 
} 

Giả sử C# < 6, hiệu quả nhất là để bắt một cụ Exception loại và đừng xử lý trên cơ sở đó. Bất kỳ nhận tất cả xử lý có thể được thực hiện riêng rẽ

try 
{ 
} 
catch (Web2PDFException ex) 
{ 
} 

hoặc

try 
{ 
} 
catch (Web2PDFException ex) 
{ 
} 
catch (Exception ex) 
{ 
} 

hoặc (nếu bạn cần phải viết một handler chung - mà nói chung là một ý tưởng tồi, nhưng nếu bạn chắc chắn đó là tốt nhất cho bạn, bạn chắc chắn):

if(err is Web2PDFException) 
{ 
} 

hoặc (trong một số trường hợp nếu bạn cần phải làm một số hệ thống phân cấp thứ loại phức tạp hơn mà không thể được thể hiện với is)

if(err.GetType().IsAssignableFrom(typeof(Web2PDFException))) 
{ 
} 

hoặc chuyển sang VB.NET hoặc F # và sử dụng is hoặc Type.IsAssignableFrom trong Filters Exception

+0

if (err là Web2PDFException) là tôi cần :) – Tomas

+0

Để sử dụng " là "nhà điều hành anh ta không cần phải chuyển sang VB.NET –

+0

@BeowulfOF: Tôi biết, nhưng nếu anh ta chỉ cố gắng lọc dựa trên các loại - tức là một số loại đánh bắt có điều kiện, v.v., có thể hữu ích khi sử dụng là * trong một bộ lọc ngoại lệ hơn là một khối catch * - nó có thể là một cách tiếp cận hoạt động. Đề nghị ban đầu của tôi (và nó vẫn còn trong câu trả lời) là một trong khối catch. Điểm mấu chốt ở đây là cho rằng sử dụng 'is' thường là một mùi hôi, chúng ta cũng có thể có một danh sách các giải pháp khả thi và để Tomas chọn những gì phù hợp nhất với anh ấy trong bối cảnh cụ thể của anh ấy. Nhưng có, nó không chắc. –

15
try 
{ 
    // Some code 
} 
catch (Web2PDFException ex) 
{ 
    // It's your special exception 
} 
catch (Exception ex) 
{ 
    // Any other exception here 
} 
+0

Nếu có 10 trường hợp ngoại lệ đã biết, chuỗi bắt sẽ trông xấu. – derek

1

Bạn nên luôn luôn bắt ngoại lệ như bê tông càng tốt, vì vậy bạn nên sử dụng

try 
{ 
    //code 
} 
catch (Web2PDFException ex) 
{ 
    //Handle the exception here 
} 

Bạn có thể sử dụng một cái gì đó như thế này nếu bạn nhấn mạnh:

try 
{ 
} 
catch (Exception err) 
{ 
    if (err is Web2PDFException) 
    { 
     //Code 
    } 
} 
5
try 
{ 
} 
catch (Exception err) 
{ 
    if (err is Web2PDFException) 
     DoWhatever(); 
} 

nhưng có thể có cách tốt hơn để làm bất cứ điều gì bạn muốn.

+0

Tại sao điều này lại được bình chọn? Nó tương đương với một số ví dụ khác. – jp2code

1

bạn có thể thêm một số thông tin thêm để ngoại trừ của bạn trong lớp học của bạn và sau đó khi bạn bắt ngoại trừ bạn có thể kiểm soát thông tin tùy chỉnh của bạn để xác định ngoại trừ của bạn

this.Data["mykey"]="keyvalue"; //you can add any type of data if you want 

và sau đó bạn có thể nhận được giá trị của mình

string mystr = (string) err.Data["mykey"]; 

như thế để biết thêm thông tin: http://msdn.microsoft.com/en-us/library/system.exception.data.aspx

+0

Bạn không chắc chắn tại sao điều này lại bị giảm giá. Điều này cung cấp một cách hay để cung cấp dữ liệu bổ sung cho mã của bạn. – jp2code

+0

@ jp2code Tôi đoán vì nó không trả lời OP? –

54

Khi giao dịch với các tình huống mà tôi don 't chính xác biết những loại ngoại lệ có thể đi ra khỏi một phương pháp, một chút "lừa" tôi muốn làm là để khôi phục tên lớp của ngoại lệ và thêm nó vào nhật ký lỗi để có thêm thông tin.

try 
{ 
    <code> 

} catch (Exception caughtEx) 
{ 
    throw new Exception("Unknown Exception Thrown: " 
         + "\n Type: " + caughtEx.GetType().Name 
         + "\n Message: " + caughtEx.Message); 
} 

Tôi đảm bảo luôn xử lý các loại ngoại lệ, đặc biệt khi xử lý mã từ những người yêu thích nắm bắt tất cả các loại chung.

+6

Tôi đang bối rối ở đây (đặc biệt là bởi các upvotes). Bạn đang thay thế một ngoại lệ hữu ích bằng stacktrace với một ngoại lệ khác chỉ có điểm nổi bật? Ngay cả khi bạn đã thực hiện ngoại lệ tham chiếu đến 'caughtEx' như một đứa trẻ, tôi tự hỏi điểm là gì (nếu bạn hiển thị toàn bộ' exception.ToString() 'nó sẽ hiển thị cho bạn kiểu anyway). Tôi có thể hiểu nếu bạn đã đăng nhập vào thời điểm này trước khi thực hiện một 'ném; '... –

+4

Trong trường hợp của tôi, tôi cần điều này cho mục đích ghi nhật ký, vì vậy' caughtEx.GetType(). Name' là chính xác những gì tôi đang tìm kiếm . Cảm ơn! – mayabelle

+0

@RubenBartelink Có, Thực tế lý do là để có ngoại lệ hiển thị trong một tệp nhật ký thay vì dấu vết ngăn xếp hơi gây khó chịu. Như với bất cứ điều gì, nó phụ thuộc vào những gì bạn cần. Tôi thường mã xử lý ngoại lệ như vậy trong quá trình phát triển vì vậy tôi có thể dễ dàng theo dõi lỗi, và sau đó làm sạch chúng hoặc điều chỉnh chúng khi cần thiết (gọi các dấu vết ngăn xếp khi cần thiết). Như tôi đã nói, tôi chủ yếu sử dụng điều này khi làm việc với các codebases, nơi các nhà phát triển trước đã bỏ qua việc xử lý ngoại lệ thích hợp. – Oskuro

1

Hoặc:

var exception = err as Web2PDFException; 

if (excecption != null) 
{ 
    Web2PDFException wex = exception; 
    .... 
} 
4

Thay vì mã hóa cứng và biên dịch lại, tại sao không chỉ gọi phương thức GetType tắt của các ngoại lệ thực tế sử dụng Visual Studio debugger không?

Để thực hiện điều đó, trong khi gỡ lỗi, người ta có thể gọi phương thức bằng cách sử dụng Immediate Window của trình gỡ lỗi. Ví dụ tôi cần phải biết những gì ngoại trừ là và chỉ trích các Name tài sản của GetType như vậy mà không cần phải biên dịch lại:

enter image description here

Các vấn đề liên quan