Tài liệu API sẽ cho bạn biết cách sử dụng API. Nhưng khi mọi thứ diễn ra không như ý muốn, bạn có thể bị bỏ mặc cho riêng mình. Thông báo lỗi thường không đầy đủ, gây hiểu lầm hoặc không hữu ích. Và bạn phải làm gì với NoMethodError: undefined method '[]' for nil:NilClass , dù sao?
Khi bạn tìm hiểu một API, khung công tác hoặc thư viện, bạn không thể chỉ học cách sử dụng nó khi mọi thứ diễn ra tốt đẹp. Bạn cũng cần phải tìm ra những gì phải làm khi nó xuất hiện lại lỗi.
Bạn ngắt mã như thế nào?
Có một cách dễ dàng để biết phải làm gì khi API bạn đang sử dụng bị hỏng. Hãy tự mình phá vỡ nó!
Ví dụ:tôi sẽ:
-
Chuyển dữ liệu không đúng loại. Bạn có thể chuyển một biểu tượng thay vì một Chuỗi, một Chuỗi thay vì một Mảng, một Hash thay vì một Mảng, những thứ tương tự như vậy.
-
Chuyển dữ liệu không đầy đủ. Bạn có thể vượt qua
nil, hàm băm không có một số trường được điền và các đối tượng vừa được khởi tạo. -
Nếu API yêu cầu quyền truy cập mạng, hãy ngắt kết nối khỏi WiFi hoặc kéo cáp mạng. Nó chỉ hết thời gian hay nó cho bạn biết dịch vụ nào nó không thể kết nối được?
-
Nếu API cho phép bạn chuyển vào một khối, hãy ném các ngoại lệ vào bên trong khối hoặc trả về dữ liệu không đúng loại .
Một API tuyệt vời sẽ cho bạn biết bạn đã làm gì sai. Một API xuất sắc sẽ cho bạn biết cách khắc phục nó. Nhưng thông thường nhất, bạn sẽ gặp phải NoMethodError của Ruby , nil không mong đợi s, hoặc tệ hơn, nhận lại các giá trị trả về hoàn toàn kỳ lạ.
Tại sao phải ngắt mã?
Đây không phải là tất cả xấu. Nếu bạn đang chơi với một viên ngọc mã nguồn mở, bạn có thể dành thời gian để hiểu ở đâu hành vi không mong đợi đó đến từ đâu và tại sao nó đã xảy ra. Bạn có thể gỡ lỗi và đọc một chút mã để tìm hiểu thêm về cách hoạt động của thư viện hoặc API.
Khi bạn phát hiện ra NoMethodError ở đâu đến từ, bạn có thể tiến thêm một bước nữa. Bạn có thể sửa thông báo lỗi cho người tiếp theo gặp phải sự cố này là có thật! Các bản sửa lỗi thông báo nhỏ tạo ra những đóng góp tuyệt vời cho nguồn mở và các yêu cầu kéo dễ dàng. Và chúng làm cho toàn bộ hệ sinh thái Ruby tốt hơn một chút cho những người khác.
Ngay cả khi đó là API REST mã nguồn đóng, bạn vẫn có thể lấy được thứ gì đó từ bài tập này. Sau khi bạn thấy các lỗi khác nhau mà bạn sẽ gặp phải từ API, bạn sẽ có thời gian dễ dàng hơn trong việc khắc phục sự cố khi bạn gặp lỗi thực sự.
Khi bạn cảm thấy thoải mái hơn khi nhìn thấy và sửa lỗi trong mã xung quanh mình, bạn sẽ thấy mã bị hỏng là một câu đố cần giải. Bạn sẽ không tự động rút lui khi nhìn thấy một ngoại lệ và dấu tích nền được đưa ra màn hình. Thay vào đó, bạn sẽ xem chúng như một cơ hội để tìm hiểu thêm về hệ thống mà bạn đang làm việc.
Cuối cùng, bạn sẽ biết rằng khi mã bị ngắt, bạn sẽ có thể ghép chúng lại với nhau. Bạn sẽ cải thiện sự tự tin của mình khi dùng thử các thư viện và API mới. Và sự táo bạo đó sẽ làm tăng tỷ lệ của bạn học những điều mới.