2011-11-09 25 views
14

Đã xem video WWDC ngày hôm nay về các tính năng mới trong xCode 4. Họ đã đề cập rằng nên sử dụng các tác vụ của nhật ký trên các điểm ngắt cùng với hành động "tự động tiếp tục sau khi đánh giá" để cho ra giá trị của biến thay vì sử dụng NSLogs mọi lúc.cách tạo hành động thông điệp nhật ký của điểm ngắt trong xcode?

phép nói rằng tôi có một cái gì đó như thế:

NSLog(@"URL is : %@", userDocumentsURL); 

Làm thế nào tôi sẽ viết một hành động nhắn đăng nhập để hiển thị giá trị userDocumentsURL không? Có thực sự là một ý tưởng tốt để sử dụng phương pháp trên thay vì NSLog?

Trả lời

25

Tạo hành động 'Tin nhắn nhật ký' của Breakpoint. Đối với nội dung log bao gồm một cái gì đó như:

URL is @(char*) [[userDocumentsURL description] UTF8String]@ 

Hoặc bạn có thể tạo ra một breakpoint 'Debugger lệnh' hành động tương tự như:

po [NSString stringWithFormat:@"URL is: %@", userDocumentsURL] 

Tôi thích sử dụng hành động breakpoint cho khai thác gỗ, vì nó cho là dễ dàng hơn để xóa ra một loạt các điểm ngắt hơn là loại bỏ NSLogs. Một nhược điểm có thể xảy ra khi sử dụng các điểm ngắt trong thời trang này là chúng chậm hơn đáng kể (trong quá trình gỡ lỗi) so với một NSLog trực tiếp.

+4

Tôi ước gì tôi biết lý do tại sao một: trình gỡ lỗi là thật ngu ngốc khi yêu cầu char * cast, và b: nó không làm việc một nửa thời gian và c: tài liệu apple không làm cho nó rõ ràng bạn cần char * và d: tại sao nó không phàn nàn nếu các biến không tồn tại để giúp bạn gỡ lỗi. So sánh với các điểm ngắt Eclipse cho Java mà thậm chí không có tính năng này, vì vậy sẽ kém hơn nhiều, nhưng cho phép bạn hack nó bằng cách đặt một bản in trong một điều kiện. Điều này gây phiền nhiễu cho nhật thực nhưng ngay cả như vậy vẫn còn dễ dàng hơn nhiều vì bản in không yêu cầu đúc đặc biệt và nó sẽ dừng lại và cho bạn biết về các lỗi – Rhubarb

-3

Tôi nhận thấy rằng tính năng chỉnh sửa điểm ngắt, trong khi hữu ích và có lẽ hiện đại, không cam kết kiểm soát nguồn, do đó không quy mô cho một nhóm nhà phát triển. Vì lý do này, tôi sẽ nói rằng khi làm việc trên một nhóm dưới sự kiểm soát nguồn để gắn bó với việc ghi nhật ký dựa trên mã như NSLog.

+4

Tôi tin rằng điều đó sẽ xảy ra nếu bạn chọn các tùy chọn chia sẻ chính xác trong trình chỉnh sửa điểm ngắt. Tôi không sử dụng tính năng này bản thân mình (nhà phát triển solo), nhưng các cuộc đàm phán WWDC chỉ ra rằng việc chia sẻ tích hợp với kiểm soát nguồn. – mbm29414

+12

Theo ý kiến ​​của tôi không bị buộc phải đọc tất cả các đầu ra gỡ lỗi của các thành viên khác trong nhóm là một người chuyên nghiệp. Bạn không phải làm sạch NSLog (hoặc // trước NSLog) trước khi cam kết. Tôi đã làm việc trên một nhóm mà 1 trong 10 cam kết đã được "gỡ bỏ đăng nhập", "thêm NSLog", "thay đổi NSLog để được nhiều hơn/ít tiết" hoặc bất cứ điều gì khác liên quan đến khai thác gỗ. –

+0

Giống như @MatthiasBauch vừa nhận xét điều này cũng có thể hữu ích.Và mặt khác, bạn nên biết, có một số usecases mà bạn không muốn khởi động lại ứng dụng nhưng muốn xem một bản ghi trong trình gỡ lỗi, vì vậy đây sẽ là khả năng duy nhất để làm điều này. –

19

Đây là giải pháp tương tự sử dụng NSLog, có thể ít ký tự hơn các giải pháp khác.

debugger command using NSlog

Tuy nhiên, trừ khi bạn thêm các void như thế này:

po (void)NSLog(@"the person name is: %@", p.name) 

bạn sẽ nhận được một gây phiền nhiễu "nil" in ra với đăng nhập của bạn. ví dụ:

(lldb) po NSLog(@"foo") 
nil 
2013-06-19 14:42:59.025 TheMove[95864:c07] foo 

(lldb) po (void)NSLog(@"foo") 
2013-06-19 14:43:10.758 TheMove[95864:c07] foo 

Nếu bạn có thể sống với con số không (Tôi có thể) đó là nhanh hơn để gõ và dễ nhớ chỉ là po