Khi nào nên sử dụng và khi nào không sử dụng Try Catch Cuối cùng

Question

Tôi đang tạo ứng dụng web asp.net trong .net 3.5 và tôi muốn biết khi nào nên sử dụng và khi nào không sử dụng Try Catch Cuối cùng chặn? Đặc biệt, phần lớn các bản thử của tôi được bao bọc xung quanh việc thực hiện các procs được lưu trữ và điền vào các trường văn bản hoặc các khung nhìn lưới? Bạn có sử dụng Try Catch EVERYTIME khi bạn thực thi proc được lưu trữ và điền một điều khiển hiển thị dữ liệu không?

khối mã của tôi thường trông giống như:

protected void AddNewRecord() 
    { 
     try 
     { 
      //execute stored proc 
      // populate grid view controls or textboxes 
     } 
     catch (Exception ex) 
     { 
      //display a messagebox to user that an error has occured 
      //return 
     } 
     finally 
     { } 
    } 

Answer 1

Câu trả lời là "nó phụ thuộc".

Bạn có thể muốn sử dụng try{...} catch {...} xung quanh mọi hoạt động nguyên tử để nếu có sự cố, bạn có thể quay lại trạng thái tốt cuối cùng (sử dụng giao dịch). Đây có thể là một hoặc nhiều thủ tục được lưu trữ - nó phụ thuộc vào ứng dụng của bạn.

Nếu bạn đang đặt ngoại lệ, hãy đảm bảo bạn rõ ràng trong trường hợp ngoại lệ bạn bắt được. Bạn không nên có catch (Exception ex) hoặc catch() - được gọi là xử lý ngoại lệ "bắt tất cả" - nhưng có các câu lệnh bắt cụ thể như catch (IndexOutOfRangeException ex) (ví dụ) thay thế.

Tuy nhiên, nếu bạn không thể xử lý ngoại lệ hoặc không có gì bạn có thể làm để dọn dẹp, thì bạn không nên bẫy nó.

Answer 2

Hầu hết thời gian bạn không nên bắt ngoại lệ. Một số nơi có ý nghĩa để nắm bắt ngoại lệ, ví dụ:

Khi bạn có thể khôi phục từ ngoại lệ cụ thể đó. Khi bạn cần đăng nhập hoặc báo cáo (ví dụ: cho người dùng) - thường ở cấp cao nhất trong mã của bạn. Khi người gọi mã của bạn không thể xử lý các ngoại lệ, vì vậy bạn cần phải chuyển đổi chúng thành một số định dạng lỗi khác.

Ngoài ra, câu lệnh chặn sử dụng có thể được sử dụng để thực sự gọi là Vứt bỏ trên các đối tượng IDisposable, loại bỏ nhu cầu thử ... cuối cùng.

Answer 3

Bạn chỉ nên sử dụng try catch, khi bạn định xử lý ngoại lệ trong khối catch. Những gì tôi có nghĩa là bằng cách xử lý là, đăng nhập lỗi, chọn một con đường khác nhau vì lỗi, vv Nếu bạn chỉ đơn thuần là ý định tái ném nó, không có điểm trong có cố gắng bắt.

Answer 4

Như những người khác đã nói, điều đó phụ thuộc. Tôi có xu hướng sử dụng các khối try/catch/finally trong hai trường hợp:

• Tôi cần xử lý Ngoại lệ theo cách nào đó khác ngoài việc chỉ đơn giản là ném lại.

• Tôi cần dọn sạch một số tài nguyên trong khối finally.

Khác với hai tình huống đó, tôi để mã gọi xử lý bất kỳ Ngoại lệ nào có thể xảy ra.

Answer 5

Bên cạnh đó với những gì người khác đã nói, hãy chắc chắn để tránh làm điều này:

try 
    { 
     throw new ApplicationException("Fake sql ex"); 
    } 
    //catch and do nothing. swallowing exceptions 
    catch(Exception){ }     

Answer 6

gì là Exception bạn đang mong đợi từ các proc lưu trữ?Cung cấp cho bạn không sử dụng pokemon exception handling và biết chính xác ứng dụng của bạn được mong đợi làm gì, bất kỳ thứ gì không phù hợp với Ngoại lệ cụ thể bạn muốn bắt sẽ bị đối tượng Application chặn lại.

Nói cách khác không sử dụng catch {} hoặc catch (Exception), nhưng xử lý ngoại lệ đặc biệt:

catch(SqlException e) 
{ 
    // Log stacktrace and show a friendly error to your user 
} 

Sự kiện Application.Error là nơi hành vi bất ngờ nên bị bắt và dễ dàng hơn để theo dõi hơn chỉ đơn giản là có một sự trở lại của khách hàng đối với bạn nói "các trường của tôi không hiển thị bất kỳ thứ gì".

Answer 7

Sử dụng "try catch" trong vòng lặp trong cùng nên tiếp tục thực hiện khi có ngoại lệ cụ thể xảy ra. Lưu ý rằng nếu bạn có vòng lặp thực hiện 10.000 lần và ngoại lệ xảy ra trên ví dụ: sự lặp lại thứ mười mà sẽ không ảnh hưởng đến 9,990 khác nó có thể hữu ích để bắt ngoại lệ và để cho vòng lặp tiếp tục đi. Mặt khác, nếu ngoại lệ chỉ ra một lỗi cho thấy lần thứ 11, 12, 13, vv qua vòng lặp cũng sẽ thất bại, sẽ nhanh hơn nhiều để cho phép ngoại lệ loại bỏ vòng lặp hơn để tiếp tục thử lại một thao tác điều đó sẽ không hoạt động.