2013-02-12 31 views
7

Tại nơi làm việc của tôi, tôi phải duy trì một số dự án C#. Các nhà phát triển ban đầu không phải là xung quanh nữa. Gần đây tôi nhận thấy một số mã lạ được tìm thấy trong các tình huống như sau:Ngoại lệ lạ Xử lý lệnh giả

try 
{ 
    //some Code 
} 
catch 
{ 
    0.ToString(); 
} 

0.ToString() là gì? Hầu hết các mã đã được viết bị căng thẳng, vì vậy tôi có thể nghĩ đến hai khả năng:

  • Đó là một placeholder (như //TODO), mà có thể tìm kiếm để biết được nơi bạn có để sửa chữa một số công cụ.
  • Đó là để tránh cảnh báo khi biên dịch cho các điều khoản bắt trống.

Có bất kỳ cách sử dụng hoặc ý thức nào khác không? Đây có phải là phong cách mã hóa tốt hay xấu hay thực hành không? Vì lệnh này không làm gì, nó sẽ có tác động nhỏ đến hiệu năng hay trình biên dịch sẽ loại bỏ nó? Cách tốt nhất để làm điều gì đó như

+7

Lý do hợp lý duy nhất là có một số mã ở đó để bạn có thể đặt điểm ngắt cho trường hợp ngoại lệ bị ném, mặc dù, không phải là cách hay để thực hiện; p – leppie

+0

Tôi đoán O là một 'đối tượng' với' null' giá trị và có một breakpoint cho 'NullReferenceException' –

+0

Âm thanh như các lập trình viên ban đầu nên đã được viết một số bài kiểm tra ... Người giữ breakpoint gỡ lỗi cũng che phủ bất kỳ trường hợp ngoại lệ ... –

Trả lời

2

Như ý kiến ​​gợi ý, mẫu mã chứa một điều lạ và một điều xấu.

0.ToString(); 

gần như chắc chắn là có một dòng mã nơi trình gỡ lỗi có thể đặt điểm ngắt. Đây là một trong những dòng lạ mà tôi đã nhìn thấy được sử dụng cho mục đích này. Có khả năng là dòng này đã bị vô tình vô tình sau một phiên gỡ lỗi.

Riêng biệt đó là khối trống catch, thường không phải là ý tưởng hay. Ryan Gates đưa ra một câu trả lời tốt cho điều đó, vì vậy tôi sẽ không mở rộng vào thời điểm đó. Nhưng điều mỉa mai là nếu có một khối đánh bắt thích hợp, sẽ có một dòng mã để đặt điểm ngắt.

1

Không có lý do nào khác hoặc lý do hợp lý để thực hiện việc này. Nó là một thực hành mã hóa xấu. Mã của bạn không nên bắt bất kỳ ngoại lệ nào mà nó không thể xử lý được.

Con đường tốt nhất là xóa nó. Khi một ngoại lệ được ném ra, bạn cần phải hiểu rằng usecase. Sau đó và chỉ sau đó bạn có thể thêm các kiểm tra thích hợp và/hoặc mã xử lý ngoại lệ cụ thể.

Mã được đề cập là ví dụ về swallowing the exception, which is hazardous to your health.