Tải bản đầy đủ (.pdf) (8 trang)

Tài liệu Xử lí ngoại lệ phần cuối pdf

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (182.92 KB, 8 trang )

Kết quả:

E3 – Custom Exception Situation!
Retrieving exception history... E2 -
Func2 caught divide by zero E1 –
DivideByZeroException
-----------------------------------------------------------------------------

Để hiểu rõ hơn ta có thể dùng trình debugger để chạy từng bước chương trình khi đó
ta sẽ hiểu rõ từng bước thực thi cũng như việc phát sinh các ngoại lệ.


Chương trình bắt đầu với việc gọi hàm DangerousFunc1() trong khối try:

try

{


DangerousFunc1();

}


DangerousFunc1() gọi DangerousFunc2(), DangerousFunc2() lại gọi
DangerousFunc3(), và cuối cùng DangerousFunc3() gọi DangerousFunc4(). Tất cả
việc gọi này điều nằm trong khối try. Cuối cùng, DangerousFunc4() phát sinh ra
ngoại lệ DivideByzeroException. Ngoại lệ này bình thường có chứa thông điệp bên
trong nó, nhưng ở đây chúng ta tự do dùng thông điệp mới. Để dễ theo dõi chúng ta
đưa vào các chuỗi xác nhận tuần tự các sự kiện diễn ra.
Ngoại lệ được phát sinh trong DangerousFunc4() và nó được bắt trong khối


catch
trong hàm DangerousFunc3(). Khối catch trong DangerousFunc3() sẽ bắt các
ngoại lệ Arithmetic- Exception ( như là DivideByZeroException), nó không thực
hiện hành động nào mà chỉ đơn giản là phát sinh lại ngoại lệ:
catch ( System.ArithmeticException)

{


throw;

}


Cú pháp để thực hiện phát sinh lại cùng một ngoại lệ mà không có bất cứ bổ sung hay
hiệu chỉnh nào là : throw.
Do vậy ngoại lệ được phát sinh cho DangerousFunc2(), khối catch trong
DangerousFunc2() thực hiện một vài hành động và tiếp tục phát sinh một ngoại lệ có
kiểu mới. Trong hàm khởi dựng của ngoại lệ mới, DangerousFunc2() truyền một
chuỗi thông điệp mới (“E2 - Func2 caught divide by zero”) và ngoại lệ ban đầu. Do
v
ậy ngoại lệ ban đầu (E1) trở thành ngoại lệ bên trong của ngoại lệ mới (E2). Sau đó
hàm DangerousFunc2() phát sinh ngoại lệ này (E2) cho hàm DangerousFunc1().
DangerousFunc1() bắt giữ ngoại lệ này, làm một số công việc và tạo ra một ngoại lệ
mới có kiểu là MyCustomException, truyền vào hàm khởi dựng của ngoại lệ mới
một chuỗi mới (“E3 – Custom Exception Situation!”) và ngoại lệ được bắt giữ (E2).
Chúng ta nên nhớ rằng ngoại lệ được b
ắt giữ là ngoại lệ có chứa ngoại lệ
DivideByZeroException (E1) bên trong nó. Tại thời điểm này, chúng ta có một ngoại lệ
kiểu MyCustomException (E3), ngoại lệ này chứa bên trong một ngoại lệ kiểu

Exception (E2), và đến lượt nó chứa một ngoại lệ kiểu DivideByZeroException
(E1) bên trong. Sau cùng ngoại lệ được phát sinh cho hàm TestFunc;
Khi khối catch của TestFunc thực hiện nó sẽ in ra thông điệp của ngoại lệ :

E3 – Custom Exception Situation!
sau đó từng ngoại lệ
bên trong sẽ được lấy ra thông qua vòng lặp while:

while ( inner != null)

{



Console.WriteLine(“{0}”, inner.Message);

inner = inner.InnerException;

}


Kết quả là chuỗi các ngoại lệ được phát sinh và được bắt giữ:

Retrieving exception history...

E2 - Func2 caught divide by
zero E1 – DivideByZero
Exception

Câu hỏi và trả lời


Câu hỏi 1
: Việc sử dụng catch không có tham số có vẻ như có nhiều sức mạnh do chúng
bắt
giữa tất cả các ngoại lệ. Tại sao chúng ta không luôn luôn sử dụng câu lệnh catch
không có tham số để bắt các lỗi?
Trả lời 1
: Mặc dù sử dụng catch duy nhất có rất nhiều sức mạnh, nhưng nó cũng làm
mất rất nhiều thông tin quan trọng về ngoại lệ được phát sinh. Khi đó chúng ta sẽ
không biết chính xác loại ngoại lệ xảy ra và khó có thể bảo trì cũng như khắc phục
những ngoại lệ sau này. Về phía người dùng cũng vậy. Nếu chương trình gặp ngoại
lệ mà không có thông báo rõ ràng cho nguời dùng thì có thể làm cho họ hoang
mang, và có thể
đổ lỗi cho chương trình của chúng ta không tốt ngay cả những lỗi
không phải do ta. Ví dụ như lỗi hết tài nguyên bộ nhớ
do người dùng sử dụng quá nhiều chương trình hoạt động cùng lúc. Tóm lại là chúng ta
nên
sử dụng catch với những tham số chi tiết để thực hiện tốt việc quản lý các ngoại lệ được
phát sinh.
Câuhỏi
2: Có phải tất cả những ngoại lệ được đối xử một cách bình đẳng?
Trả lời 2
: Không phải, có hai loại ngoại lệ, ngoại lệ hệ thống và ngoại lệ của chương
trình ứng dụng. Ngoại lệ của chương trình ứng dụng thì sẽ không kết thúc
chương trình. Còn ngoại lệ hệ thống thì sẽ kết thúc chương trình. Nói chung đó là
những ngoại lệ xuất hiện trước đây. Hiện nay thì người ta chia ra nhiều mức độ
ngoại lệ và tùy theo từng mức độ c
ủa ngoại lệ mà chương trình của chúng ta sẽ được
nhận những ứng xử khác nhau. Để biết thêm
chi tiết chúng ta có thể đọc thêm trong tài liệu .NET Framework về xử lý ngoại lệ.

Câuhỏi
3: Như câu trả lời bên trên tại sao tôi phải tìm hiểu nhiều về các ngoại lệ và cách
thức
xử lý các ngoại lệ khi chúng được phát sinh?
Trả lời 3: Việc xây dựng một chương trình ứng dụng là hết sức phức tạp, chương
trình luôn tiếm ẩn những yếu tố không ổn định và có thể phát sinh các ngoại lệ
dẫn đến những lỗi không mong muốn. Việc thực hiện bắt giữ các ngoại lệ là hết
sức cần thiết trong chương trình, nó cho phép chúng ta xây dựng được chương trình
hoàn thiện hơn và xử lý các thông điệp ngoại lệ t
ốt hơn. Tìm hiểu những ngoại lệ
đem đến cho chúng ta nhiều kinh nghiệm trong việc xây dựng các chương trình
phức tạp hơn.
Câu hỏi thêm

Câuhỏi 1: Hãy cho biết các từ khóa được sử dụng để xử lý ngoại lệ?

×