reinhardtA commented 7 years ago

Hab den Fehler noch mal nachgestellt ... vor dem git pull ... damit es nicht verloren geht ..

ich habe Laufen ein : Linux andreas-VirtualBox 4.4.0-59-generic #80-Ubuntu SMP Fri Jan 6 17:47:47 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

und es crashed: Starting program: /home/andreas/Development/requirements/build/req [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7ffff655d700 (LWP 2414)] terminate called after throwing an instance of 'requirements::Exception' what(): Invalid or no command

Thread 1 "req" received signal SIGABRT, Aborted. 0x00007ffff6ab9428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 54 ../sysdeps/unix/sysv/linux/raise.c: Datei oder Verzeichnis nicht gefunden. (gdb) bt 20

0 0x00007ffff6ab9428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54

1 0x00007ffff6abb02a in __GI_abort () at abort.c:89

2 0x00007ffff70f284d in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6

3 0x00007ffff70f06b6 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6

4 0x00007ffff70f0701 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6

5 0x00007ffff70f0919 in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6

6 0x00007ffff7b76fc7 in requirements::commands::assembleFromString (str="") at /home/andreas/Development/requirements/src/requirements/commands/command.cpp:57

7 0x00000000004086d3 in main (argc=1, args=0x7fffffffdef8) at /home/andreas/Development/requirements/src/req/main.cpp:51

JulianSchutsch commented 7 years ago

Hahaha. Ok, nun zur Erläuterung:

Es gibt 2 Klassen von Exceptions:

Hardware-Exceptions/Betriebssystem-Exceptions
Nutzer-Exceptions

Du hattest ein Segfault erwähnt, das ist ein sehr schweres Exception. Das wäre jetzt eine Debug-Session wert gewesen.

Der hier gezeigte Exception deutet nur darauf hin, daß die Konsolenanwendung noch kein besseres Fehlerdarstellungssystem hatte, daher die Fehlermeldungen schlicht als std::exception am Schluss ausgegeben hat. Sicher kein Lieferwürdiger Zustand, jedoch nicht mal Ansatzweise so schlimm wie ein Segfault.

Das Fehler-Exceptionsystem befand sich bis vor kurzem in einer Designphase, es wurde modifiziert um verschiedene Arten von Fehlern zu transportieren und für die Internationalisierung offen gehalten. Gegenüber dem hier erwähnten Stand wurde modifiziert:

::requirements::Exception hat jetzt ein Kind, der zwischen Internen und Nutzerfehlern unterscheidet
Die Parameter des Exceptions (z.B. Dateiname, UUID eines Elements) werden separat von der Fehlermeldung im Exception gespeichert.

Erst jetzt hat es also Sinn ergeben, die Fehlermeldung im Konsolenprogramm aufzubereiten, das Exception wird jetzt daher abgefangen und per util::formatString in einer hoffentlich verständliche (noch nicht internationalisierte) Fehlermeldung umgewandelt.

Bisher, daher in dem Stand den Du getestet hast, habe ich schlicht auf das what(): geachtet und die Fehlermeldung direkt ausgelesen. Er zeigt hier nicht mehr an, daß kein Befehl auf der Konsole angegeben wurde.

Es ist halt ein Programm im frühen Entwicklungsstadium.