Bài giảng Kỹ thuật lập trình - Chương 5: Lập trình phòng thủ - Lương Mạnh Bá

Nội dung text: Bài giảng Kỹ thuật lập trình - Chương 5: Lập trình phòng thủ - Lương Mạnh Bá

1. DEFENSIVE PROGRAMMING? • Xuất phát từ khái niệm defensive driving. • Khi lái xe bạn luôn phải tâm niệm rằng bạn không bao giờ biết chắc được người lái xe khác sẽ làm gì. Bằng cách đó, bạn có thể chắc chắn rằng khi họ làm điều gì nguy hiểm, thì bạn sẽ không bị ảnh hưởng ( tai nạn). • Bạn có trách nhiệm bảo vệ bản thân, ngay cả khi người khác có lỗi • Trong defensive programming, ý tưởng chính là nếu chương trình (con) được truyền dữ liệu tồi, nó cũng không sao, kể cả khi với CT khác thì sẽ bị fault. • Một cách tổng quát, lập trình phòng thủ nghĩa là : làm thế nào để tự bảo vệ mình khỏi thế giới lạnh lùng, tàn nhẫn của dữ liệu không hợp lệ, các sự kiện mà có thể "không bao giờ" xảy ra, và các lập trình viên khác ‘sai lầm’ SE-SoICT KTLT 5.2 Last update 09-2010
2. Ba cách để xử lý rác vào • Kiểm tra giá trị của mọi dữ liệu từ nguồn bên ngoài – Khi nhận dữ liệu từ file, bàn phím, mạng, hoặc từ các nguồn ngoài khác, hãy kiểm tra đê đảm bảo rằng dữ liệu nằm trong giới hạn cho phép. – Hãy đảm bảo rằng giá trị số nằm trong dung sai và xâu phải đủ ngẵn để xử lý. Nếu một chuỗi được dự định để đại diện cho một phạm vi giới hạn của các giá trị (như một ID giao dịch tài chính hoặc một cái gì đó tương tự), hãy chắc chắn rằng các chuỗi là hợp lệ cho mục đích của nó; nếu không phải từ chối . – Nếu bạn làm việc trên 1 ứng dụng bảo mật, hãy đặc biệt lưu ý đến những dữ liệu có thể tấn công hệ thống :làm tràn bộ nhớ, injected SQL commands, injected html hay XML code, tràn số SE-SoICT KTLT 5.4 Last update 09-2010
3. 2 Assertions • 1 macro hay 1 CT con dùng trong quá trình phát triển ứng dụng, cho phép CT tự kiểm tra khi chạy. • Return true >> OK, false >> có 1 lỗi gì đó trong CT. • VD : Nếu hệ thống cho rằng file dữ liệu về khách hàng không bao giờ vượt quá 50 000 bản ghi, CT có thể chứa 1 assertion rằng số bản ghi là <= 50 000. Khi mà số bản ghi <= 50,000, assertion sẽ không có phản ứng gì. Nếu đếm hơn 50 000 bản ghi, nó sẽ lớn tiếng “khẳng định” rằng có 1 lỗi trong CT. SE-SoICT KTLT 5.6 Last update 09-2010
4. • ND cuối không cần thấy các thông báo của assertion ; • Assertions chủ yếu được dùng trong quá trình phát triển hay bảo dưỡng ứng dụng. • Dịch thành mã khi phát triển, loại bỏ khỏi mã trong sản phẩm >>hiệu quả. SE-SoICT KTLT 5.8 Last update 09-2010
5. Guidelines for Using Assertions • Sử dụng mã xử lý lỗi với những điều kiện ta chờ đợi sẽ xảy ra; Dùng assertions cho các ĐK không mong đợi ( không bao giờ xảy ra) – Error-handling : kiểm tra với lỗi đầu vào – Assertions : kiểm tra có bugs trong CT – Error handling hướng tới việc xử lý lỗi, còn assertion thì hướng đến việc hiệu chỉnh chương trình , tạo ra các phiên bản của PM. • Tránh đưa mã xử lý vào trong assertions – Điều gì xảy ra khi ta turn off the assertions ? SE-SoICT KTLT 5.10 Last update 09-2010
6. 3. Kỹ thuật xử lý lỗi (Error Handling Techniques) • Error handling dùng để xử lý các lỗi mà ta chờ đợi sẽ xảy ra • Tùy theo tình huống cụ thể, ta có thể trả về 1 giá trị trung lập, thay thế đoạn tiếp theo của dữ liệu hợp lệ, trả về cùng giá trị như lần trước, thay thế giá trị hợp lệ gần nhất, Ghi vết 1 cảnh báo vào tệp, trả về 1 mã lỗi, gọi 1 thủ tục hay đối tượng xử lý, hiện 1 thông báo hay tắt máy. SE-SoICT KTLT 5.12 Last update 09-2010
7. 4. Xử lý ngoại lệ - Exceptions • Exception : bắt các tình huống bất thường và phục hồi chúng về trạng thái trước đó. • Dùng Ngoại lệ để thông báo cho các bộ phận khác của chương trình về lỗi không nên bỏ qua – Lợi ích của ngoại lệ là khả năng báo hiệu điều kiện lỗi . Phương pháp tiếp cận khác để xử lý các lỗi tạo ra khả năng mà một điều kiện lỗi có thể truyền bá thông qua một cơ sở mã không bị phát hiện. Ngoại lệ có thể loại trừ khả năng đó. • Chỉ dùng ngoại lệ cho những điều kiện thực sự ngoại lệ – Exceptions đc dùng trong những tình huống giống assertions— cho các sự kiện không thường xuyên, nhưng có thể không bao giờ xảy ra – Exception có thể bị lạm dụng và phá vở các cấu trúc, điều này dễ gây ra lỗi, vì làm sai lệch luồng điều khiển SE-SoICT KTLT 5.14 Last update 09-2010
8. Dim tran As SqlTransaction Try conn.Open() tran = conn.BeginTransaction() SqlHelper.ExecuteNonQuery(tran, "ThemHDon",_ HDInfo.SoHoaDonTC, HDInfo.TenKhach, _ HDInfo.PhuongThucTT) iMaHD = GetMaHoaDon_Integer(tran) For Each objCT In arrDSCT SqlHelper.ExecuteNonQuery(tran, "ThemChiTietHD", objCT.ChiTiet, _ objCT.SoTienVND, iMaHDP) Next tran.Commit() Catch ex As Exception tran.Rollback() End Try SE-SoICT KTLT 5.16 Last update 09-2010
9. 5.Gỡ rối – debbuging • Các chương trình đã viết có thể có nhiều lỗi ? – tại sao phần mềm lại phức tạp vây ? • Sự phức tạp của CT liên quan đến cách thức tương tác của các thành phần của CT đó, mà 1 phần mềm lại bao gồm nhiều thành phần và các tương tác giữa chúng • Nhiều kỹ thuật làm giảm số lượng các thành phần tương tác : – Che giấu thông tin – Trừu tượng hóa • Có các kỹ thuật nhàm đảm bảo tính toàn vẹn thiết kế phần mềm – Documentation – Lập mô hình – Phân tích các yêu cầu – Kiểm tra hình thức • Nhưng chưa có 1 kỹ thuật nào làm thay đổi cách thức xây dựng phần mềm => luôn xuất hiện lỗi khi test, phai loại bỏ = gỡ rối ! SE-SoICT KTLT 5.18 Last update 09-2010
10. • Động lực chính cho việc cải tiến các ngôn ngữ LT là cố gắng ngăn chặn các lỗi thông qua các đặc trưng ngôn ngữ như : – Kiểm tra các giới hạn biên của các chỉ số – Hạn chế không dùng con trỏ, bộ dọn dẹp, các kiểu dữ liệu chuỗi – Xác định kiểu nhập/xuất – Kiểm tra dữ liệu chặt chẽ. • Mỗi ngôn ngữ cũng có những đặc tính dễ gây lỗi : lệnh goto, biến toàn cục, con trỏ trỏ tới vùng không xác định, chuyển kiểu tự động • LTV cần biết trước những đặc thù để tránh các lỗi tiềm ẩn, đồng thời cần kích hoạt mọi khả năng kiểm tra của trình biên dịch và quan tâm đến các cảnh báo • Ví dụ : so sánh C,Pascal, VB SE-SoICT KTLT 5.20 Last update 09-2010
11. Understand Error Messages Gỡ rối khi build-time dễ hơn lúc run-time, khi và chỉ khi ta (1) Hiểu đc các thông báo lỗi!!! • Một số là từ tiền xử lý (preprocessor) Misspelled #include file #include int main(void) /* Print "hello, world" to stdout and return 0. { Missing */ printf("hello, world\n"); return 0; } $ gcc217 hello.c -o hello hello.c:1:20: stdioo.h: No such file or directory hello.c:3:1: unterminated comment hello.c:2: error: syntax error at end of input SE-SoICT KTLT 5.22 Last update 09-2010
12. Understand Error Messages (tt) (1) Hiểu đc các thông báo lỗi!!! • Một số là từ nối kiểm (linker) #include Misspelled int main(void) function name /* Print "hello, world" to stdout and return 0. */ { prinf("hello, world\n") return 0; } Compiler warning (not error): Linker error: Cannot find prinf() is called before declared definition of prinf() $ gcc217 hello.c -o hello hello.c: In function `main': hello.c:6: warning: implicit declaration of function `prinf' /tmp/cc43ebjk.o(.text+0x25): In function `main': : undefined reference to `prinf' collect2: ld returned 1 exitSE status-SoICT KTLT 5.24 Last update 09-2010
13. Các phương pháp gỡ rối • Có đầu mỗi , phát hiện dễ ràng (Good clues, easy bugs) : – Khi có lỗi, ta thường cho là trình dịch, thư viện hay bất cứ nguyên nhân nào khác Tuy nhiên, cuối cùng thì lỗi vẫn thuộc về CT. – Rất may là hầu hết các lỗi thường đơn giản và dễ tìm. Hãy khảo sát các đầu mối của việc xuất ra kq có lỗi và cố gắng suy ra nguyên nhân gây ra nó – Khi có đc 1 số thông tin về lỗi và nơi xảy ra lỗi, hãy tạm dừng để ngẫm nghĩ xem lỗi xảy ra như thế nào? – Suy luận ngược trở lại trạng thái của CT bị hỏng để xđ nguyên nhân gây ra lỗi – Gỡ rối liên quan đến việc lập luận lùi, giỗng như tìm kiếm các bí mật của 1 vụ án. 1 số vđề không thể xảy ra và chỉ có những thông tin xác thực mới đáng tin cậy. => phải đi ngược từ kết quả để khám phá nguyên nhân, khi có lời giải thích đầy đủ, ta sẽ biết đc vấn đề cần sửa và có thể phát hiện ra 1 số vđề khác SE-SoICT KTLT 5.26 Last update 09-2010
14. Các phương pháp gỡ rối • Kiểm tra sự thay đổi mới nhất – Lỗi thường xảy ra ở những đoạn CT mới đc bổ sung – Nếu phiên bản cũ OK, phiên bản mới có lỗi => lỗi chắc chắn nằm ở những đoạn CT mới – Lưu ý, khi sửa đổi, nâng cấp : hãy giữ lại phiên bản cũ – đơn giản là comment lại đoạn mã cũ – Đặc biệt, với các hệ thống lớn, làm việc nhóm thì việc sử dụng các hệ thống quản lý phiên bản mã nguồn và các cơ chế lưu lại quá trình sửa đổi là vô cùng hữu ích ( source safe ) SE-SoICT KTLT 5.28 Last update 09-2010
15. Các phương pháp gỡ rối • Xem các vết (stack trace) – Thường người gỡ rối có thể thực hiện CT, 1 cách chung nhất là kiểm tra trạng thái CT khi bị lỗi. TD như số hiệu dòng mã nguồn cũng là 1 phần của chồng vết. Xét VD sau: int arr[N]; qsort (arr, N, sizeof(arr[0],icmp) Do sự bất cẩn, người lập trình gõ scmp thay vì icmp.=> Đương nhiên là ct dịch không thể phát hiện lỗi này và khi thực hiện ct đó, lỗi sẽ xảy ra và tạo nên 1 chồng vết: 0. strcmp(0x1a2,0x1c2)[“strcmp, s”:31 1. scmp (p1=0x10001048,p2=0x1000105c)[badqs.c”:13] 2. qst(0x 10001048, 0x 10001074,0 x 400b20,0x4) [“qsort.c”:147] . 5. _istart () [“crt s”:13] => CT có lỗi ớ trcmp SE-SoICT KTLT 5.30 Last update 09-2010
16. Các phương pháp gỡ rối • Đọc trước khi gõ vào – Đừng vội vàng, khi không rõ điều gì thực sự gây ra lỗi và sửa không đúng chỗ sẽ có nguy cơ gây ra lỗi khác – Có thể viết đoạn code gây lỗi ra giấy=> tạo cách nhìn khác, và tạo cơ hội để nghĩ suy – Đừng miên man chép cả đoạn không có nguy cơ gây lỗi, hoặc in toàn bộ code ra giấy in => phá vỡ cây cấu trúc SE-SoICT KTLT 5.32 Last update 09-2010
17. Không có đầu mối khó gỡ lỗi (No clues, hard bugs) • Làm cho lỗi xuất hiện lại – Cố gắng làm cho lỗi có thể xuất hiện lại khi cần – Nếu không đc, thì thử tìm nguyên nhân tại sao lại không đc • Chia để trị – Thu hẹp phạm vi – Tập trung vào dữ liệu gây lỗi SE-SoICT KTLT 5.34 Last update 09-2010
18. Hiển thị KQ In các giá trị tại các điểm nhạy cảm –Poor: stdout is buffered; CT printf("%d", keyvariable); có thể có lỗi trước khi hiện ra output –Maybe better: In '\n' sẽ xóa bộ nhớ printf("%d\n", keyvariable); đệm stdout , nhưng sẽ không xóa khi in ra file –Better: Gọi fflush() để làm sạch printf("%d", keyvariable); buffer 1 cách tường fflush(stdout); minh SE-SoICT KTLT 5.36 Last update 09-2010
19. Các phương pháp gỡ rối • Phương sách cuối cùng (last resorts-p 128) – Dùng 1 trình gỡ rối để chạy từng bước – Nhiều khi vấn đề tưởng quá đơn giản nhưng lại không phát hiện được, ví dụ các toán tử so sánh trong Pascal va VB có độ ưu tiên ngang nhau, nhưng với C ? Chú ý đặc trưng NN. ( == và != nhỏ hơn !) – Thứ tự các đối số của lời gọi hàm : ví dụ : strcpy(s1,s2) int m[6]={1,2,3,4,5,6}, *p,*q; p=m; q=p+2; *p++ =*q++; *p=*q; ??? – Lỗi loại này khó tìm vì bản thân ý nghĩ của ta vạch ra 1 hướng suy nghĩ sai lệch : coi điều không đúng là đúng – Đôi khi lỗi là do nguyên nhân khách quan : Trình biên dịch, thư viện hay hệ điều hành, hoặc lỗi phần cứng : 1994 lỗi xử lý dấu chấm động trong bộ xử lý Pentium. SE-SoICT KTLT 5.38 Last update 09-2010
20. Các công cụ gỡ lỗi (p 131) • SE-SoICT KTLT 5.40 Last update 09-2010
21. Thêm – Những lỗi thường gặp với C, C++ 1. Array as a parameter handled improperly – Tham số mảng đc xử lý không đúng cách 2. Array index out of bounds – Vượt ra ngoài phạm vi chỉ số mảng 3. Call-by-value used instead of call-by reference for function parameters to be modified – Gọi theo giá trị, thay vì gọi theo tham chiếu cho hàm để sửa 4. Comparison operators misused – Các toán tử so sánh bị dùng sai 5. Compound statement not used - Lệnh phức hợp không đc dùng 6. Dangling else - nhánh else khong hợp lệ 7. Division by zero attempted - Chia cho 0 8. Division using integers so quotient gets truncated – Dùng phép chia số nguyên nên phần thập phân bị cắt 9. Files not closed properly (buffer not flushed) - File không đc đóng phù hợp ( buffer không bị dẹp) 10. Infinite loop - lặp vô hạn 11. Global variables used – dùng biến tổng thể SE-SoICT KTLT 5.42 Last update 09-2010
22. 22. Off-by-one error in a loop – Thoát khỏi bởi 1 lỗi trong vòng lặp 23. Overused (overloaded) local variable names - Trùng tên biến cục bộ 24. Pointers not set properly or overwritten in error – Con trỏ không đc xác định đúng hoặc trỏ vào 1 vị trí không có 25. Return with value attempted in void function – trả về 1 giá trị trong 1 hàm void 26. Undeclared variable name – không khai báo biến 27. Un-initialized variables – Không khởi tạo giá trị 28. Unmatched parentheses – thiếu } 29. Un-terminated strings - xâu không kết thúc , thiếu “ 30. Using "=" when "= =" is intended or vice versa 31. Using "&" when "&&" is intended or vice versa 32. "while" used improperly instead of "if“ – while đc dùng thay vì if SE-SoICT KTLT 5.44 Last update 09-2010