2011-11-09 7 views
14

Oglądałem dzisiaj wideo WWDC o nowych funkcjach w kodzie 4. Wspomnieli, że dobrym pomysłem jest użycie akcji z wiadomościami logicznymi na punktach przerwania wraz z włączeniem "automatycznie kontynuuj po działaniach ewaluacyjnych", aby wyprowadzić wartość zmiennej dla przykładu zamiast używać NSLogs cały czas.jak utworzyć akcję logowania punktu przerwania w xcode?

powiedzmy mam coś takiego:

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

Jak napisać skargę wiadomość dziennika, aby wyświetlić wartość userDocumentsURL za? Czy naprawdę dobrym pomysłem jest użycie powyższej metody zamiast NSLog?

Odpowiedz

25

Utwórz akcję "Zapisz wiadomość" w punkcie przerwania. Do wiadomości dziennika zawierać coś takiego:

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

Alternatywnie można utworzyć punkt przerwania „Debugger polecenia” działanie podobne do:

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

Wolę użyciu punktu przerwania działania dla pozyskiwania drewna, jak to zapewne łatwiej wyczyścić out of breakpoints niż jest usunięcie NSLogs. Możliwą wadą używania punktów przerwania w ten sposób jest to, że są znacznie wolniejsze (podczas debugowania) niż bezpośredni NSLog.

+4

Chciałbym wiedzieć, dlaczego: debugger jest tak głupi, by wymagać char * cast, i b: to nie działa przez połowę czasu i c: dokumentacja Apple nie wyjaśnia, że ​​potrzebujesz znaku * i d: dlaczego nie narzeka, jeśli zmienne nie istnieją, aby pomóc Ci w debugowaniu. Porównaj z punktami przerwania Eclipse dla Javy, które nie mają tej funkcji, więc powinna być znacznie gorsza, ale możesz ją zhakować, umieszczając druk w stanie. Jest to denerwujące zaćmienie, ale mimo to jest jeszcze łatwiejsze, ponieważ druk nie wymaga specjalnego odlewania, a zatrzyma się i powie Ci o błędach. – Rhubarb

-3

Zauważam, że funkcja edycji punktów przerwania, choć użyteczna i być może nowoczesna, nie angażuje się w kontrolę nad źródłami, więc nie skaluje się do zespołu programistów. Z tego powodu, powiedziałbym, że pracując nad zespołem pod kontrolą źródła, trzymam się rejestrowania opartego na kodzie, takiego jak NSLog.

+4

Uważam, że tak, jeśli wybierzesz prawidłowe opcje udostępniania w edytorze punktów przerwań. Nie korzystam z tej funkcji osobiście (programista solo), ale rozmowy WWDC wskazują, że udostępnianie integruje się z kontrolą źródła. – mbm29414

+12

Moim zdaniem nie być zmuszonym do czytania wszystkich wyników debugowania innych członków zespołu jest pro. Nie musisz czyścić NSLog (lub // przed NSLogiem) przed popełnieniem. Pracowałem w zespole, w którym 1 na 10 commitów to "usunięte logowanie", "dodano więcej NSLog", "zmieniono NSLog na bardziej/mniej gadatliwy" lub cokolwiek innego związanego z logowaniem. –

+0

Podobnie jak komentarz @MatthiasBauch, który właśnie skomentował, może być przydatny.Z drugiej strony powinieneś wiedzieć, że istnieje kilka przypadków użycia, w których nie chcesz ponownie uruchamiać aplikacji, ale chciałbyś zobaczyć dziennik w debugerze, więc byłaby to jedyna możliwość zrobienia tego. –

19

Oto podobne rozwiązanie z użyciem NSLog, które może mieć mniej znaków niż inne rozwiązania.

debugger command using NSlog

Jednakże, chyba że dodasz void takiego:

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

dostaniesz przykry "nil" wydrukowana ze swoim dzienniku. na przykład:

(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 

Jeśli można żyć z zera (mogę) to szybciej wpisywać i łatwiejsze do zapamiętania tylko po