2012-11-29 36 views
9

Chúng tôi có loại có nhà điều hành chuỗi ẩn. Nó trông giống như thế này:Các toán tử ngầm có nên xử lý null không?

public class Foo 
{ 
    readonly string _value; 

    Foo(string value) 
    { 
     _value = value; 
    } 

    public static implicit operator string(Foo foo) 
    { 
     return foo._value; 
    } 

    public static implicit operator Foo(string fooAsText) 
    { 
     return new Foo(fooAsText); 
    } 

} 

Chúng tôi vừa có một kịch bản mà trường hợp truyền cho các nhà điều hành ngầm là null. Rõ ràng, chúng tôi đã kết thúc với một NullReferenceException. Tôi nghĩ rằng điều này là công bằng, sau khi tất cả, những gì đại diện chuỗi của một loại đó là null - khó nói - vì vậy ngoại lệ có vẻ hợp lệ và một cái gì đó chúng ta không nên đánh chặn/đàn áp/xử lý/bỏ qua. Lý do của tôi là dọc theo dòng của 'ai đó đã cho tôi một null, tại sao tôi nên trả về null. Tôi không làm điều này trong các phương pháp khác '. Tôi nghĩ, 'Tôi biết, tôi sẽ chỉ cần kiểm tra cho null trước khi chuyển đổi nó, một cái gì đó như:

string s = foo == null ? null : foo;

Nhưng điều đó không làm việc, bởi vì nó bây giờ chuyển đổi thành một chuỗi trước so sánh với null. Tất nhiên, so sánh này sẽ hoạt động:

Foo f = null; 
string s; 
if (f != null) 
{ 
    s = f; 
} 

... nhưng điều đó thật xấu xí.

tôi đọc phần trong Essential C# 5 4th edition (một cuốn sách 'Cắt giảm Rough' trên Safari) và nó nói:

KHÔNG ném ngoại lệ từ chuyển đổi tiềm ẩn.

này nói không ném trường hợp ngoại lệ, nhưng nó để lại tôi tự hỏi nên tôi ngăn chặn trường hợp ngoại lệ?

Điều rõ ràng nhất để làm là để nhảy vào phương pháp và thay đổi nó để:

public static implicit operator string(Foo foo) 
{ 
    return foo == null ? null : foo._value; 
} 

Vấn đề giải quyết. Nhưng tôi cảm thấy bẩn thỉu. Tôi cảm thấy như tôi đang ẩn một lỗi tiềm năng bằng cách kiểm tra null. Tôi có bị hoang tưởng/hậu môn/ngu ngốc không?

+1

tất cả phụ thuộc vào trường hợp sử dụng của bạn. bạn có muốn 'chuỗi' là null không? –

+1

Điểm tốt. Lý tưởng nhất là chúng tôi muốn không bao giờ đi qua một ví dụ null của một 'Foo'. Hmmm ... Có lẽ nó phải là một cấu trúc ... –

+2

@SteveDunn: Một điều quan trọng: Một 'NullReferenceException' luôn luôn chỉ ra một lỗi trong mã làm tăng ngoại lệ, * không * trong việc gọi mã. Vì vậy, đơn giản là không kiểm tra 'foo' cho' null' là một lỗi trong toán tử. –

Trả lời

12

Điều tôi muốn giới thiệu trong trường hợp này là toán tử có thể bị lỗi phải rõ ràng hơn là ngầm định. Ý tưởng về một chuyển đổi tiềm ẩn là nó được mở rộng (tức là nó sẽ không bao giờ thất bại.) Chuyển đổi rõ ràng, mặt khác, được hiểu đôi khi có thể thất bại.

+1

Đó cũng là những gì tài liệu đề xuất: http://msdn.microsoft.com/en-us/library/z5z9kes2.aspx –

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