seeseekey.net - Invictus Deus Ex Machina

Reguläre Ausdrücke sind mächtig. Wenn man einen solchen Ausdruck entwickelt z.B. um eine Zeichenkette zu extrahieren, ist es enorm hilfreich das ganze zeitnah zu debuggen. Mit der Webseite regexr.com gibt es dafür einen Dienst mit welchem eigene reguläre Ausdrücke schnell überprüft und getestet werden können. Dabei wird der Ausdruck auf der Seite eingegeben und anschließend gegen den angegebenen Text überprüft.

regexr.com

regexr.com

Daneben bietet der Dienst eine Reihe von Zusatzfunktionalitäten, wie die von Nutzern befüllte Bibliothek von regulären Ausdrücken für bestimmte Funktionalitäten. Der Quelltext des Dienstes ist auf GitHub zu finden – er ist unter der MIT-Lizenz lizenziert und damit freie Software.

Wenn man unter JavaScript entwickelt so benutzt man sicher auch folgende Zeile ab und an in abgewandelter Form:

alert("XYZ");

Das Problem an „alert“ ist das es für viele Sachen unpraktikabel ist. Schöner wäre hier eine Konsole in die man diese Meldungen hineinschreiben könnte und die auch browserunabhängig funktioniert. Genau hier kommt Blackbird ins Spiel welches unter http://www.gscottolson.com/blackbirdjs/ zu finden ist.

Blackbird im Einsatz.

Mit der Konsole ist es möglich verschiedene Loglevel zu realisieren und das ganze einfach in das Projekt seiner Wahl einzubinden. Der weitere Vorteil ist, das man die Debugmeldungen im Gegensatz zu einem „alert“ auch einfach im Quelltext stehen lassen kann und die Ausgabe nur bei Bedarf aktiviert.

Für die Webentwicklung ist es manchmal ganz Hilfreich die Struktur der Webseite, also die verschachtelten Tags übersichtlich visualisiert zu bekommen. Dabei ist das Firefox AddOn „Tilt“ sehr hilfreich. Dieses stellt die Verschachtelung der Seite als 3D Modell (mit Hilfe von WebGL) dar, im welchem man dann die Elemente untersuchen kann.

Zu finden ist das AddOn unter https://addons.mozilla.org/en-US/firefox/addon/tilt/.

Manchmal kann einen die Softwareentwicklung schon in den Wahnsinn treiben, vor allem wenn es um triviale Dinge geht. So sollte es ja eigentlich selbstverständlich sein, das der Debugger an einem Haltepunkt hält. Mein erster Gedanke war, das es daran liegt das ich das Projekt im Debugmodus auf „Any CPU“ eingestellt habe. Sobald ich es auf „x86“ oder „x64“ gestellt habe, hielt der Debugger an der gewünschten Stelle. Allerdings hatte ich ein ähnliches Projekt mit fast den selben Einstellungen (auch „Any CPU“), doch dort funktionierte es mit dem Debugger. Also sollte es ein Vergleich der Projektdateien richten. Nach einiger Zeit war hier auch kein Erfolg zu melden.

Beim Starten des Projektes fiel mir allerdings auf das die Haltepunkte ausgeblendet wurden:

Im Tooltip zu den Haltepunkten stand dann:

No symbols have been loaded for this document

Dies brachte mich dazu in das „bin/Debug“ Verzeichnis zu schauen und siehe da, es gab keine pdb Dateien für das Projekt. Um die pdb Dateien für das Projekt anzulegen, geht man in die Projekteinstellungen, dort auf „Build“ und dann auf „Advanced“.

In dem sich darauf öffnenden Dialog stellt man die „Debug info“ auf „full“. Damit sollten die PDB Dateien erzeugt werden und das debuggen wieder funktionieren.

Weitere Informationen gibt es unter:
http://en.wikipedia.org/wiki/Program_database
http://msdn.microsoft.com/en-us/library/yd4f8bd1%28v=vs.71%29.aspx
http://geekswithblogs.net/dbutscher/archive/2007/06/26/113472.aspx
http://www.wintellect.com/CS/blogs/jrobbins/archive/2009/05/11/pdb-files-what-every-developer-must-know.aspx

Ich stelle vor ein paar Tagen ein .NET Projekt von .NET 2 auf .NET 4 um. An dem Projekt hingen einige Bibliotheken welche weiterhin auf .NET 2 basierten (und dies auch weiterhin tun sollen). Nach der Umstellung ergab sich nun das Problem, das ich die Anwendung nicht mehr mit dem Debugger starten konnte.

Das Problem hängt dabei damit zusammen das das Visual Studio für .NET 1 bis .NET 3.5 sowie für .NET 4 jeweils eine eigene Debugengine benutzt. Um das Problem zu umgehen schaltete ich in den Projekteigenschaften unter Debug den Eintrag Enable the Visual Studio hosting process aus. Danach konnte ich auch mit dem gemischten Projekt wieder debuggen.

Weitere Informationen gibt es unter:
http://blogs.msdn.com/b/debugger/archive/2010/04/30/can-t-hit-breakpoints-in-a-plug-in-or-can-t-debug-net-2-0-3-0-3-5-from-a-mixed-mode-exe-project-with-visual-studio-2010.aspx

Zu Debugzwecken ist es manchmal ganz praktisch den Inhalt einer Variable (im konkreten Fall in PHP) auszugeben. Das würde unter PHP dann so aussehen:

echo $test;

Das Problem an dieser Methode ist, das wenn es sich um ein Array handelt, wir nur die Ausgabe:

Array

zurückbekommen. Hier hilft die print_r Funktion, mit welcher das ganze dann so aussieht:

print_r($test);

Damit bekommt man dann eine wunderschöne Ausgabe des Arrays:

Array ( [0] => 1232 [1] => 1775 [2] => 8532 [3] => 3432 [4] => 1232 [5] => 384 [6] => 4357 [7] => 4334 [8] => 9888 [9] => 2442 [10] => 1212 [11] => 9989 [12] => 543 )

Wenn man unter Eclipse Android Anwendungen debuggen möchte hat man es gar nicht so ein einfach. Jeder der das ausprobieren möchte sollte folgende Zeile in die onCreate Methode einer Activity hinzufügen (nach setContentView):

int error=7/0;

Diese Zeile führt zu einer Division durch Null Exception. Würde man sowas nun in C# machen und im Debugmodus ausführen so wird eine Exception ausgelöst und der Debugger zeigt genau die Stelle im Originalcode an an der der Fehler auftritt. So weiß man gleich wo der Fehler zu finden ist.

Wenn wir nun besagtes Beispiel in Eclipse im Debugmodus starten passiert jedoch etwas anderes. Der Debugger hält irgendwo in der Datei ActivityThread Datei an mit der Meldung das er den Source nicht finden kann. Also welche Möglichkeiten bleiben?

Das Debugfenster ist in diesem Moment auch nicht wirklich hilfreich. Ein wenig mehr hilft der LogCat View (wenn er nicht vorhanden ist, einfach über Window -> Show View -> Other hinzufügen) in die Exception angezeigt wird.

Bei unserer Exception müsste dort dann stehen:

Caused by: java.lang.ArithmeticException: divide by Zero

Darunter steht dann der Callstack inklusive Zeilennummer. Damit ist die Sache dann schon ein wenig angenehmer 🙂

Weitere Informationen gibt es unter:
http://www.anddev.org/a_solution_for_source_not_found_in_eclipse-t3151.html

Wenn man Android Anwendungen mittels Eclipse programmiert so ist man auch in Besitz eines ausgewachsenen Debuggers, welcher einem bei der Fehlersuche hilfreich zur Seite steht. Damit wir etwas zum debuggen haben, bauen wir einen kleinen Fehler in unserer Hello World Programm ein. Das ganze sieht dann so aus:

package net.seeseekey.hello_world;

import android.app.Activity;
import android.os.Bundle;
import android.widget.TextView;

public class hello_world extends Activity {
/** Called when the activity is first created. */
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);

int result = 42/0;

TextView tv = new TextView(this);
tv.setText(result);
setContentView(tv);
}
}

Wenn wir das Programm starten stürzt es im Emulator ab, da eine Division durch Null nicht sehr beliebt ist. Um nun zu Debuggen müssen wir einen Breakpoint setzen. Diesen Breakpoint setzen wir an die Zeile int result = 42/0;. Ein Breakpoint wird gesetzt in dem man links von Quellcode auf der vertikalen Leiste eine Doppelklick vollführt.

Mittels Run -> Debug oder der F11 Taste starten wir das Programm im Debugmodus. Beim ersten Start im Debugmodus fragt uns Eclipse ob wir in die Debugansicht springen möchten was wir ablehnen. Das Programm startet dann ganz normal im Emulator bis der Debugger genau an der Stelle unterbricht wo wir den Breakpoint gesetzt haben.

Nun könnten wir z.B. den Term 42/0 in das Expression Fenster ziehen (Window -> Show View -> Other… -> Debug -> Expressions) und sehen dann das bei der Operation eine Divide by Zero herauskommt.

In dem View Debug befinden sich außerdem die Controls um durch das Programm oder in Funktionen hinein zu steppen. Soviel zum Debugging mittels Eclipse und Android 🙂