Phương pháp ưu tiên để xử lý các giá trị enum bất ngờ là gì?

Question

Giả sử chúng ta có phương thức chấp nhận giá trị của một liệt kê. Sau khi phương pháp này kiểm tra rằng giá trị là hợp lệ, nó switch es trên các giá trị có thể. Vì vậy, câu hỏi đặt ra là, phương pháp ưu tiên xử lý các giá trị không mong muốn là gì sau khi phạm vi giá trị đã được xác thực?

Ví dụ:

enum Mood { Happy, Sad } 

public void PrintMood(Mood mood) 
{ 
    if (!Enum.IsDefined(typeof(Mood), mood)) 
    { 
     throw new ArgumentOutOfRangeException("mood"); 
    } 

    switch (mood) 
    { 
     case Happy: Console.WriteLine("I am happy"); break; 
     case Sad: Console.WriteLine("I am sad"); break; 
     default: // what should we do here? 
    } 

phương pháp ưu tiên xử lý các trường hợp default là gì?

• Leave a comment như // can never happen
• Debug.Fail() (hoặc Debug.Assert(false))
• throw new NotImplementedException() (hoặc bất kỳ ngoại lệ khác)
• Một số cách khác mà tôi đã không nghĩ đến

Answer 1

Tôi thích throw new NotImplementedException("Unhandled Mood: " + mood). Vấn đề là việc liệt kê có thể thay đổi trong tương lai và phương pháp này có thể không được cập nhật cho phù hợp. Ném một ngoại lệ có vẻ là phương pháp an toàn nhất.

Tôi không thích phương pháp Debug.Fail(), bởi vì phương pháp này có thể là một phần của thư viện và các giá trị mới có thể không được kiểm tra ở chế độ gỡ lỗi. Các ứng dụng khác sử dụng thư viện đó có thể đối mặt với hành vi thời gian chạy lạ trong trường hợp đó, trong khi trong trường hợp ném ngoại lệ, lỗi sẽ được biết ngay lập tức.

Lưu ý: NotImplementedException tồn tại trong commons.lang.

Answer 2

Bạn có thể có một dấu vết để mặc định gọi ra giá trị của enum được truyền. Ném ngoại lệ là OK nhưng trong một ứng dụng lớn sẽ có một số nơi mà mã của bạn không quan tâm đến các giá trị khác của enum.
Vì vậy, trừ khi bạn chắc chắn rằng mã có ý định xử lý tất cả các giá trị có thể có của enum, bạn sẽ phải quay lại sau và loại bỏ ngoại lệ.

Answer 3

Trong Java, cách tiêu chuẩn là để ném một AssertionError, vì hai lý do:

1. Điều này đảm bảo rằng ngay cả khi asserts bị vô hiệu hóa, một lỗi được ném.
2. Bạn đang khẳng định rằng không có giá trị enum nào khác, do đó, AssertionError sẽ ghi lại các giả định của bạn tốt hơn NotImplementedException (trong đó Java không có).

Answer 4

Đối với khá nhiều mỗi câu lệnh switch trong cơ sở mã của tôi, tôi có trường hợp mặc định sau

switch(value) { 
... 
default: 
    Contract.InvalidEnumValue(value); 
} 

Phương pháp này sẽ ném một ngoại lệ quy định chi tiết giá trị của enum tại điểm một lỗi được phát hiện.

public static void InvalidEnumValue<T>(T value) where T: struct 
{ 
    ThrowIfFalse(typeof(T).IsEnum, "Expected an enum type"); 
    Violation("Invalid Enum value of Type {0} : {1}", new object[] { typeof(T).Name, value }); 
} 

Answer 5

Gọi nó là ý kiến ​​hoặc tùy chọn, nhưng ý tưởng đằng sau enum là nó đại diện cho danh sách đầy đủ các giá trị có thể. Nếu một "giá trị không mong muốn" đang được truyền xung quanh trong mã, thì enum (hoặc mục đích đằng sau enum) không được cập nhật. Sở thích cá nhân của tôi là mỗi enum mang một nhiệm vụ mặc định là Undefined.Cho rằng enum là một danh sách được xác định, nó sẽ không bao giờ bị lỗi thời với mã tiêu thụ của bạn.

Theo như những gì cần làm nếu hàm của bạn nhận được một giá trị không mong muốn hoặc Không xác định trong trường hợp của tôi, câu trả lời chung dường như không thể. Đối với tôi, nó phụ thuộc vào bối cảnh lý do để đánh giá giá trị enum: đó có phải là một tình huống mà việc thực thi mã phải tạm dừng hoặc có thể sử dụng giá trị mặc định không?

Answer 6

Ý kiến ​​của tôi là vì đó là lỗi lập trình, bạn nên khẳng định hoặc ném một RuntimException (Java, hoặc bất kỳ tương đương nào cho các ngôn ngữ khác). Tôi có UnhandledEnumException của riêng tôi mà kéo dài từ RuntimeException mà tôi sử dụng cho việc này.

Answer 7

Đó là trách nhiệm của hàm gọi để cung cấp đầu vào hợp lệ và bất kỳ thứ gì không có trong enum không hợp lệ (trình lập trình thực dụng dường như hàm ý điều này). Điều đó nói rằng, điều này ngụ ý rằng bất cứ khi nào bạn thay đổi enum của mình, bạn phải thay đổi TẤT CẢ mã chấp nhận nó làm đầu vào (và mã SOME tạo ra nó làm đầu ra). Nhưng đó có lẽ là sự thật. Nếu bạn có một enum thay đổi thường xuyên, bạn có lẽ nên sử dụng một cái gì đó khác hơn là một enum, xem xét rằng enums thường là các thực thể biên dịch.

Answer 8

Phản hồi chương trình chính xác sẽ là die theo cách cho phép nhà phát triển dễ dàng phát hiện sự cố. mmyers và JaredPar cả hai đều có những cách tốt để thực hiện điều đó.

Tại sao lại chết? Điều đó có vẻ quá khắc nghiệt!

Lý do là nếu bạn không xử lý giá trị enum đúng cách và chỉ rơi qua, bạn sẽ đặt chương trình của mình thành trạng thái không mong muốn. Một khi bạn đang ở trong trạng thái bất ngờ, ai biết chuyện gì đang xảy ra. Điều này có thể dẫn đến dữ liệu xấu, lỗi khó theo dõi hoặc thậm chí là lỗ hổng bảo mật.

Ngoài ra, nếu chương trình chết, có nhiều khả năng bạn sẽ bắt nó trong QA và do đó nó thậm chí không đi ra khỏi cửa.

Answer 9

Tôi thường cố gắng để xác định giá trị không xác định (0):

enum Mood { Undefined = 0, Happy, Sad } 

Bằng cách đó tôi luôn luôn có thể nói:

switch (mood) 
{ 
    case Happy: Console.WriteLine("I am happy"); break; 
    case Sad: Console.WriteLine("I am sad"); break; 
    case Undefined: // handle undefined case 
    default: // at this point it is obvious that there is an unknown problem 
      // -> throw -> die :-) 
} 

Đây là ít nhất cách tôi thường làm điều này.

Answer 10

Đây là một trong những câu hỏi đó chứng minh lý do tại sao phát triển theo thử nghiệm là rất quan trọng.

Trong trường hợp này, tôi sẽ đi cho một NotSupportedException bởi vì nghĩa đen giá trị đã được unhandled và do đó không được hỗ trợ. Một NotImplementedException cung cấp thêm ý tưởng: "Điều này chưa hoàn thành";)

Mã gọi có thể xử lý tình huống như thế này và các bài kiểm tra đơn vị có thể được tạo để dễ dàng kiểm tra các loại tình huống này.

Answer 11

Đối với C#, điều đáng biết là Enum.IsDefined() is dangerous. Bạn không thể dựa vào nó như bạn. Bắt một cái gì đó không phải của các giá trị dự kiến ​​là một trường hợp tốt cho ném một ngoại lệ và chết lớn tiếng. Trong Java, nó khác nhau bởi vì enums là các lớp không phải là số nguyên vì vậy bạn thực sự không thể nhận được các giá trị không mong muốn (trừ khi enum được cập nhật và câu lệnh switch của bạn không), đó là một lý do chính tại sao tôi thích Java enums .Bạn cũng phải phục vụ cho các giá trị null. Nhưng nhận được một trường hợp không null bạn không nhận ra là một trường hợp tốt cho ném một ngoại lệ quá.

Answer 12

Tôi đoán hầu hết các câu trả lời ở trên đều hợp lệ, nhưng tôi không chắc chắn là đúng.

Câu trả lời đúng là bạn hiếm khi chuyển sang ngôn ngữ OO, nó cho biết bạn đang làm sai OO của mình. Trong trường hợp này, đó là một dấu hiệu hoàn hảo cho thấy lớp Enum của bạn có vấn đề.

Bạn chỉ nên gọi Console.WriteLine (mood.moodMessage()) và xác định moodMessage cho từng trạng thái.

Nếu một trạng thái mới được thêm vào - Tất cả mã của bạn nên thích ứng tự động, không có gì nên thất bại, ném ngoại lệ hoặc cần thay đổi.

Chỉnh sửa: trả lời nhận xét.

Trong ví dụ của bạn, thành "Good OO", chức năng của chế độ tệp sẽ được kiểm soát bởi đối tượng FileMode. Nó có thể chứa một đối tượng ủy nhiệm với các hoạt động "mở, đọc, viết ..." khác nhau cho mỗi FileMode, vì vậy File.open ("name", FileMode.Create) có thể được thực hiện như (xin lỗi về sự thiếu hiểu biết với API):

open(String name, FileMode mode) { 
    // May throw an exception if, for instance, mode is Open and file doesn't exist 
    // May also create the file depending on Mode 
    FileHandle fh = mode.getHandle(name); 
    ... code to actually open fh here... 
    // Let Truncate and append do their special handling 
    mode.setPosition(fh); 
} 

Đây là gọn gàng hơn nhiều so với cố gắng để làm điều đó với công tắc ... (bằng cách này, các phương pháp sẽ được cả hai gói tin và có thể giao cho "Chế độ" lớp)

Khi OO được thực hiện tốt, mọi phương thức đơn lẻ trông giống như một vài dòng mã đơn giản, dễ hiểu, rất đơn giản. Bạn luôn có được cảm giác rằng có một số lớn lộn xộn "Cheese Nucleus" tổ chức với nhau tất cả các đối tượng nacho nhỏ, nhưng bạn không bao giờ có thể tìm thấy nó - nó nachos tất cả các con đường xuống ...