Wer kann Exceptions noch explizit erklären? - 100€ Prämie! - Timeout/Deadline = 31.12.2019

[TS]

Hello,

gibt es hier überhaupt noch jemanden, der die Funktionsweise einer Exception in den jeweiligen IDEs noch vollständig bis runter auf die Prozessorebene erklären kann mit allen Seiteneffekten und Nebenbedingungen?

Ich würde für ein akzepteables Wiki-Feature 100€ Prämie ausloben. Da ich es ja bekanntermaßen nicht so dicke habe, wäre ich über weitere Sponsoren (und Lektoren) begeistert. Mein Angebot gilt vorerst bis zum 31.12.2019.

Glück Auf
Tom vom Berg

[ursus contionabundo]

gibt es hier überhaupt noch jemanden, der die Funktionsweise einer Exception in den jeweiligen IDEs noch vollständig bis runter auf die Prozessorebene erklären kann mit allen Seiteneffekten und Nebenbedingungen?

Alle IDEs, alle Programmiersprachen und dann runter über den Interpreter/Compiler bis hin zur Maschinensprache?

Ich würde für ein akzepteables Wiki-Feature 100€ Prämie ausloben.

Getaggt unter "Jobangebote".

Hehe. Wir haben ein Mindestlohngesetz. Selbst eine Linkliste wäre teurer.

[Rolf B]

Hallo TS,

ich würde es vermeiden wollen, in einer IDE eine Exception zu bekommen. Das ist nicht gut für die Nerven...

Rolf

[TS]

Hello,

ich würde es vermeiden wollen, in einer IDE eine Exception zu bekommen. Das ist nicht gut für die Nerven...

chchchch

Hast Du da nicht ein Ironie/Humor-Kennzeichen vergessen?

@ursus contionabundo:
Jedenfalls reden wir heute immer über Sachen, über die kaum noch jemand weiß, wie sie eigentlich funktionieren. Und ich habe nicht von gerechtem Lohn gesprochen für eine ausführliche Darlegung, sondern dass ICH dafür 100€ locker mache, in der Hoffnung, dass sich noch mehr Sponsoren finden würden, um eine gerechte Bezahlung zu ermöglichen ;-P

Glück Auf
Tom vom Berg

[Camping_RIDER]

Aloha ;)

Jedenfalls reden wir heute immer über Sachen, über die kaum noch jemand weiß, wie sie eigentlich funktionieren.

Ich kann Küchenmagnete auch dann vorzüglich dazu benutzen, meine Einkaufsliste damit zu befestigen, wenn ich die quantenmechanische Ursache für Magnetismus nicht verstanden habe.

Will sagen: Ein Stück weit ist es völlig normal, sich auf einem Abstraktionslevel zu bewegen, ohne die darunterliegenden zu verstehen oder verstehen zu müssen.

Grüße,

RIDER

[pl]

Will sagen: Ein Stück weit ist es völlig normal, sich auf einem Abstraktionslevel zu bewegen, ohne die darunterliegenden zu verstehen oder verstehen zu müssen.

So isses. Was OOP betrifft: Instanzen machen nur dann einen Sinn, wenn deren Methoden genutzt werden und es einen Grund gibt, diese Methoden in einem eigenen Namensraum bzw. einer eigenen Klasse zu definieren.

Und wenn die Klasse nur eine Instanz zulässt ist schon die Instanziierung fraglich.

MfG

[Camping_RIDER]

Aloha ;)

So isses. Was OOP betrifft: Instanzen machen nur dann einen Sinn, wenn deren Methoden genutzt werden und es einen Grund gibt, diese Methoden in einem eigenen Namensraum bzw. einer eigenen Klasse zu definieren.

Da würde ich dir völlig widersprechen. Ein großer Vorteil davon, wenn man Objekte als Instanz einer Klasse hat, ergibt sich gerade in typisierten Sprachen, in denen man die Struktur eines Objekts und seine Signatur durch einen einfachen Typcheck klären kann, ein großer Vorteil.

Genauso sinnvoll ist OOP immer dann, wenn man viele ähnliche Objekte hat; dann ist es durchaus auch ein Vorteil, schon für die eigene Strukturierung und Lesbarkeit, das als Instanziierung einer Klasse zu realisieren.

Und wenn die Klasse nur eine Instanz zulässt ist schon die Instanziierung fraglich.

Da hast du nicht Unrecht. Klassen, die nur ein Singleton definieren, sind aus meiner Sicht eher ein Workaround dafür, dass es in den meisten Objektorientierten Sprachen keine einzelnen Objekte ohne Klassenzugehörigkeit gibt. Hier muss man mit Sicherheit keinen Sinn suchen, der über das Argument „aber die Sprache ist eben objektorientiert“ hinausgeht.

Grüße,

RIDER

[pl]

In Sachen Exceptions sehe ich das auch so: Zum Klassifizieren braucht man keine Instanzen sondern nur Klassen. Eine Exception selbst braucht auch keine Methoden. Also ist das Erstellen einer Klasseninstanz nicht notwendig. Für mich ein klarer Fall für einen Trait.

MfG

[TS]

Hello,

In Sachen Exceptions sehe ich das auch so: Zum Klassifizieren braucht man keine Instanzen sondern nur Klassen. Eine Exception selbst braucht auch keine Methoden. Also ist das Erstellen einer Klasseninstanz nicht notwendig. Für mich ein klarer Fall für einen Trait.

Eine "Exception" ~= "Exitroutine" benötigt auch keine Klassen. Sie muss aber vom OS unterstützt werden, wenn das Programm anschließend noch ordentlich beendet werden soll für den Fall, dass sie nicht gezielt ins Programm zurückführen kann.

Glück Auf
Tom vom Berg

[pl]

Hello,

Eine "Exception" ~= "Exitroutine" benötigt auch keine Klassen.

Völlig falsch! Eine Exception ist keine Exitroutine!

Im Übrigen meldet sich jedes Programm beim Beenden an das OS zurück mit einem sogenannten Exitcode. Wobei ein Prozess beendet mit Exit-Code 255 heißt daß es per Exception beendet wurde. exit 0 hingegen ist ein fehlerfreier Return.

MfG

[ursus contionabundo]

Hello,

Eine "Exception" ~= "Exitroutine" benötigt auch keine Klassen.

Völlig falsch! Eine Exception ist keine Exitroutine!

Die "Exception" an sich nicht - deren Behandlung (und, falls programmierbar und programmiert: Erkennung) aber schon.

Ich würde schon etwas wie exit(2) als "Exitroutine" bezeichnen - weil die syntaktische Ausgestaltung als Funktionaufruf (also: call) und die nachfolgenden (wenn auch aus Sicht eines Programmierers oft "unsichtbaren") Aktionen (Man denke an allein an den Garbage Collector!) nahelegen, dass es genau das ist.

Im Übrigen meldet sich jedes Programm beim Beenden an das OS zurück mit einem sogenannten Exitcode. Wobei ein Prozess beendet mit Exit-Code 255 heißt daß es per Exception beendet wurde. exit 0 hingegen ist (regelmäßig) ein fehlerfreier Return.

Eben der Elternprozess (dem der Exit des Kindes signalsiert wird) soll (kann) den Exit-Code auswerten.

Zutreffend ist, dass Programme für den Elternprozess (also nicht für das OS!) einen Exit-Status-Code hinterlassen und dass dieser, wenn es denn keine Null ist, signalisiert: Da ging was schief (Fatale Fehler) oder aber auch: vielleicht (Notizen, Warnungen) ging was schief. Was aber genau welcher Code (!=0) signalisiert ist Vereinbarungssache und soll sich an Konventionen - die durchaus sehr unterschiedlich sind - halten.

Das jetzt PHP (und Perl) als Interpreter eine 255 als exit-code hinterlassen wenn ein Syntaxfehler (compilation error) auftrat (Perl übrigens gerne eine 9 wenn es denn ein fehlendes Package vermutet oder eine Subroutine nicht definiert ist) ist z.B. eine solche Konvention.

Beispiele (Jeweils die letzte Zeile zeigt den Exit-Code):

$> echo -e "foo bar;" | perl; echo $?
Can't locate object method "foo" via package "bar" (perhaps you forgot to load "bar"?) at - line 1.
9

$> echo -e "foo bar(;" | perl; echo $?
syntax error at - line 1, near "(;"
Execution of - aborted due to compilation errors.
255

$> echo -e "<?php\nfoo();" | php; echo $?
PHP Fatal error:  Uncaught Error: Call to undefined function foo() in Standard input code:2
Stack trace:
#0 {main}
  thrown in Standard input code on line 2
255

$> echo -e "<?php\nfoo" | php; echo $?
PHP Parse error:  syntax error, unexpected end of file in Standard input code on line 3
255

Bei diesen Beispielen geht gar nichts schief. Aber der Elternprozess (Hier der Interpreter, der diesen Exit-Code an die Shell durchreicht.) bekommt eine 3 signalisiert:

$>  echo -e "exit(3);" | perl; echo $?
3

$> echo -e "<?php\nexit(3);" | php; echo $?
3

Dann wäre da noch der Umstand, dass die Ausgabe von Fehlermeldungen auf die Error-Konsole (stderr) erfolgen kann (Ausgaben im Beipiel unten unterdrückt). Klarer Fall von "Routine" - in dem Fall des Interpreters/Kompilers.

$> echo -e "<?php\nfoo();" | php 2> /dev/null; echo $?
255

[pl]

Zutreffend ist, dass Programme für den Elternprozess (also nicht für das OS!) einen Exit-Status-Code hinterlassen

Doch genau das: Jedes Programm meldet sich mit einem bestimmten Status von 0..255 an das OS zurück!

Und selbstverständlich tun das auch PHP und Perl Scripts! Und auch dann wenn kein explizites exit 0; angewiesen wurde meldet sich ein Perlscript spontan mit Status 0 an das OS zurück -- Sofern es keinen Ausnahmefehler oder einen Absturz gab oder es per kill-Signal vom OS an Script beendet wurde.

Und das war schon immer so!

[ursus contionabundo]

Doch genau das: Jedes Programm meldet sich mit einem bestimmten Status von 0..255 an das OS zurück!

Nein. An den Parent-Prozess. Ob das OS vermittelt ist irrelevant.

[pl]

Das jetzt PHP (und Perl) als Interpreter eine 255 als exit-code hinterlassen wenn ein Syntaxfehler (compilation error) auftrat (Perl übrigens gerne eine 9 wenn es denn ein fehlendes Package vermutet oder eine Subroutine nicht definiert ist)

Auch falsch.

Undefined subroutine &main::foo called at .. pack.pl line 15.

Prozess beendet mit Exit-Code 255

MfG

[ursus contionabundo]

Das jetzt PHP (und Perl) als Interpreter eine 255 als exit-code hinterlassen wenn ein Syntaxfehler (compilation error) auftrat (Perl übrigens gerne eine 9 wenn es denn ein fehlendes Package vermutet oder eine Subroutine nicht definiert ist)

Auch falsch.

Undefined subroutine &main::foo called at .. pack.pl line 15.

Prozess beendet mit Exit-Code 255

Niemand außer Dir weiß was Du getan hast, weil Du den Code der übrigen Zeilen nicht zeigst, sondern nur Behauptungen aufstellst. Ich habe folgendes getan:

1.)

$> echo -e "foo bar;" | perl; echo $?
Can't locate object method "foo" via package "bar" (perhaps you forgot to load "bar"?) at - line 1.
9

2.)

$> echo -e "foo();" | perl; echo $?
Undefined subroutine &main::foo called at - line 1.
9

und 3.)

$> echo -e "foo bar(;" | perl; echo $?
syntax error at - line 1, near "(;"
Execution of - aborted due to compilation errors.
255

Das ist auch nachvollziehbar. (Wobei ich mir nicht ganz sicher bin, ob sich Dein spezielles Perl (wohl auch mitsamst Deinem geheimen Framework) unter Deinem speziellen OS anders verhält.) Aber aus meinen Versuchen 1.) und 2.) folgt, dass Perl "gerne mal" den Exit-Code 9 zurück gibt, "wenn es denn ein fehlendes Package vermutet oder eine Subroutine nicht definiert ist."

Obige Ergebnisse zu Versuch 1.) und 2) entsprechen ergo genau meiner Aussage, die Du als "falsch" bezeichnest - sie ist aber definitiv und nach allen Regeln der Logik richtig.

Vielleicht liegt es ja an Deinem Framework, welches die Exitcodes verhunzt. Irgendwas muss wird schließlich in Deinen geheimen Zeilen 1 bis 14 stehen.

[pl]

Das jetzt PHP (und Perl) als Interpreter eine 255 als exit-code hinterlassen wenn ein Syntaxfehler (compilation error) auftrat (Perl übrigens gerne eine 9 wenn es denn ein fehlendes Package vermutet oder eine Subroutine nicht definiert ist)

Auch falsch.

Undefined subroutine &main::foo called at .. pack.pl line 15.

Prozess beendet mit Exit-Code 255

Niemand außer Dir weiß was Du getan hast, weil Du den Code der übrigen Zeilen nicht zeigst, sondern nur Behauptungen aufstellst.

Du hast behauptet, nicht ich! Im übrigen ist klar ersichtlich, was diesen Exit-Code 255 erzeugt hat!

.

[ursus contionabundo]

Du hast behauptet, nicht ich!

Was, bitte, erzeugt: Prozess beendet mit Exit-Code 255 ?

Im übrigen ist klar ersichtlich, was diesen Exit-Code 255 erzeugt hat!

Nein. So lange nicht klar ist, was obiges erzeugt und so lange die Zeilen 1 bis 14 geheim sind ist gar nichts "klar ersichtlich".

[Rolf B]

Hallo pl,

Wenn ich ein PHP Script starte, das einen Syntax-Error enthält (Parse Error), endet PHP.EXE mit ERRORLEVEL 255.

Wenn ich ein PHP Script starte, das auf einen Fatal Error läuft (z.B. ungefangene Exception), endet PHP.EXE mit ERRORLEVEL 255.

Wenn ich ein C# Programm starte, dass nichts weiter tut als throw new Exception("Foo!");, endet der Prozess (reproduzierbar) mit ERRORLEVEL E0434352 (oder -532462766), was ein .net interner Code für das Windows SEH (Structured Exception Handling) ist.

D.h. deine Annahme mit Exit Code 255 ist auf begrenzte Beobachtungen gestützt und nicht zu verallgemeinern. Es gibt unter Windows eine Menge von definierten Systemfehlercodes, und die meisten Shell-Programme liefern sie auch zurück wenn einer davon auftritt. Aber ansonsten ist hier viel Raum für Kreativität. Perl und PHP sind hier bereits kreativ - 255 ist kleinster gemeinsamer Nenner für alle Exitcode-fähigen Betriebssystem; selbst wenn ein Exitcode nur 8-bittig sein sollte, ist 255 immer noch möglich. Unter Windows hat der Systemfehlercode 255 aber eine ganz andere Bedeutung: ERROR_EA_LIST_INCONSISTENT - The extended attributes are inconsistent. Das ist irgendein interner Error des File Systems.

Rolf

[pl]

hi @Rolf B

jeder Prozess meldet sich beim Beenden an seinen Parent. Wobei dieser Parent selbstverständlich auch das OS sein kann, so habe ich das mal gelernt. Was das OS selbst an Errorcodes definiert ist ein völlig anderes Thema.

Nur sollte beim Programmieren wenigstens die Kenntnis vorhanden sein, daß es überhaupt einen Exitstatus gibt und daß eine nicht aufgefangene Exception auch vom übergeordneten Prozess wahrgenommen wird eben über den Exit Status != 0 und eben auch vom OS.

Die diesbezügliche Dokumentation ist gerade auch in Perl sehr umfangreich, das kann jeder selber lesen. Siehe POSIX, siehe die, siehe exit, perlvar usw.

Des Weiteren gibt es für die Kommunikation unter Prozessen nicht nur den Exitstatus. So kann z.B. auch das OS an einen Perlprozess Signale senden, bspw. ein Signal zum beenden.

MfG

[TS]

Hello Hotti,

jeder Prozess meldet sich beim Beenden an seinen Parent.

Wenn er vorher abkackt, meldet sich da gar nichts mehr...

Wobei dieser Parent selbstverständlich auch das OS sein kann, so habe ich das mal gelernt. Was das OS selbst an Errorcodes definiert ist ein völlig anderes Thema.

... und man kann nur hoffen, dass OS und IDE die Teilprozesse ausreichend stabil gekapselt haben und überwachen, ob sie noch leben, oder ob sie zum Zombie geworden sind, oder ob sie einfach nur noch wirr Speicheradressen adressieren, die ihnen gar nicht gehören und deshalb tunlichst für den kaputten Prozess unerreichbar sind. Das entscheidet aber die IDE beim Zusammenstellen des Codes und den passenden Requests beim OS.

Nur sollte beim Programmieren wenigstens die Kenntnis vorhanden sein, daß es überhaupt einen Exitstatus gibt und daß eine nicht aufgefangene Exception auch vom übergeordneten Prozess wahrgenommen wird eben über den Exit Status != 0 und eben auch vom OS.

Der Exit-Status eines Programmmodules hat mMn nichts mit den Exceptions zu tun, die man als Programmierer einbaut in seinen Programmfluss. Um einen Exit-Status zu erhalten muss man seine "App" mindestens in eine virtual (real) Maschine einpacken, oder einen Fork beantragen, oder ... Das OS kümmert sich dann. Um die Exceptions kümmert es sich aber nicht. Dazu muss der Code entsprechend schlau assembliert werden.

Des Weiteren gibt es für die Kommunikation unter Prozessen nicht nur den Exitstatus. So kann z.B. auch das OS an einen Perlprozess Signale senden, bspw. ein Signal zum beenden.

Das ist mMn eine ganz andere Ebene, als die berühmten Exceptions.

Aber genaus DAS wollte ich ja von jemandem erklärt haben, der mindestens so tief einsteigen mag, wie RolfB.

Glück Auf
Tom vom Berg

[Rolf B]

Hallo Tom,

da ein Prozess nicht direkt andere aufruft, sondern das OS dazwischen hängt, kriegt das OS den 💩 mit und kann Dir dann das Klopapier rüberreichen. Ich mag das jetzt nicht testen, viel Tipparbeit, aber die Beziehung Shell ⇒ Programm ist die gleiche wie bei Programm ⇒ Subprogramm, insofern bekommt ein Programm das schon mit.

Ob man aber garantiert erkennen kann, dass ein Subprozess wegen einer ungefangenen Exception in die 💩 gerannt ist - da bin ich mir gar nicht sicher. Das mag betriebssystemspezifisch sein. In einem Russisch Roulette Betriebssystem wie DOS kann es natürlich sein, dass man gar nichts mehr mitbekommt. Weil die Exception dazu führte, dass der Instruction Pointer des Prozessors auf eine lustige Stelle im Grafikspeicher gesetzt wurde, oder so ähnlich, und die Karre nun den Dreifinger-Gruß braucht. Oder den Any Key^[1].

Ansonsten ist die Beziehung zwischen Prozessen für das Thema "Exception Handling innerhalb von Prozessen" ein Fall für die Copacabanas: "Klingt interessant" - "Ist es aber nicht".

Um die Exceptions kümmert sich (das OS) aber nicht.

Windows schon. Es stellt dafür eine Standardinfrastruktur bereit. Ob man die nutzen MUSS, weil es Funktionen im Windows API gibt, die SEH Exceptions werfen, das weiß ich nicht.

Rolf

---

1. Wenn der Computer sagt "Hit any key to continue" und ein Luser fragt, wo der ist, zeigt man auf die „Continue“-Taste am Computergehäuse. ↩︎

[Camping_RIDER]

Aloha ;)

gibt es hier überhaupt noch jemanden, der die Funktionsweise einer Exception in den jeweiligen IDEs noch vollständig bis runter auf die Prozessorebene erklären kann mit allen Seiteneffekten und Nebenbedingungen?

Ich sehe den Usecase dafür nicht so. Rein akademisch ist das zwar sicher auch ganz nett, aber magst du mir erläutern, was man davon praktisch gesehen hat, falls es da was gibt?

Grüße,

RIDER

[pl]

Gibts überhaupt noch welche die ohne IDE entwickeln können?

[JürgenB]

Ja, gibt es.

[pl]

Ja, gibt es.

Ich hatte sogar schon Kunden in meiner Hotline die es geschafft haben eine config.sys mit copy con zu schreiben.

[dedlfix]

Tach!

Gibts überhaupt noch welche die ohne IDE entwickeln können?

Ja, aber warum sollte man sich das antun?

dedlfix.

[ursus contionabundo]

• Weil der Beamer nur 1024x768px liefert.
• Weil 3(2) Kurstage für /P[a-z]{2-5}/-Grundlagen(Fortgeschritten) + IDE zu kurz sind.
• Weil manche IDEs auch nur Editoren mit Syntaxhervorhebung und einem Terminal sind.
• Weil manche IDEs natürlich an der fehlenden Umgebung für die Skripte scheitern (z.B. fehlt in PHP $_SERVER) und das Debugging dann doch anders gemacht werden muss.
• Weil die Position von ALT und TAB den Fingern bekannt sind.

Andererseits fummle ich hier gerade (unter Linux) mit mit M$ Visual Code herum und freue mich darüber, dass der beim Tippen hilft:

wenn auch etwas merkwürdig... aber das spart manchmal den Blick in die Referenz.

[dedlfix]

Tach!

• Weil der Beamer nur 1024x768px liefert.
• Weil 3(2) Kurstage für /P[a-z]{2-5}/-Grundlagen(Fortgeschritten) + IDE zu kurz sind.

Es geht ums Entwickeln, nicht um Präsentationen oder Schulungen.

• Weil manche IDEs auch nur Editoren mit Syntaxhervorhebung und einem Terminal sind.

Das soll ein Grund sein, wenigstens auf diesen Komfort zu verzichten?

• Weil manche IDEs natürlich an der fehlenden Umgebung für die Skripte scheitern (z.B. fehlt in PHP $_SERVER) und das Debugging dann doch anders gemacht werden muss.

Eine IDE ohne Debug-Unterstützung würde mich nicht daran hindern, sie zu verwenden. Wenn Debugging nicht geht, hat man immer noch die anderen Features. Deshalb einen Editor vorzuziehen sehe ich keinen Sinn darin.

Andererseits fummle ich hier gerade mit mit M$ Visual Code herum und freue mich darüber, dass der beim Tippen hilft: [...] wenn auch etwas merkwürdig... aber das spart manchmal den Blick in die Referenz.

Eben. Natürlich kann man mit einem einfachen Editor entwickeln, aber die Hilfen unterm Mausklick oder einer Tastenkombination zu haben, die man sonst umständlicher durch Aufsuchen des Browsers und Aufsuchen der entsprechenden Handbuchseite holen müsste, hilft bei der Produktivität und dem Konzentrieren auf die eigentliche Aufgabe. Mit Autovervollständigung und direkten Hinweisen auf problematische Konstrukte kommt man auch schneller voran. Nur mit einem Editor zu entwickeln, würde ich jedenfalls nicht als heroische Tat ansehen.

dedlfix.

[pl]

Eben. Natürlich kann man mit einem einfachen Editor entwickeln, aber die Hilfen unterm Mausklick oder einer Tastenkombination zu haben, die man sonst umständlicher durch Aufsuchen des Browsers und Aufsuchen der entsprechenden Handbuchseite holen müsste

Es gibt auch Editoren die sowas untersützen bzw. in denen man das Ausführen externer Kommandos auf Shortcuts legen kann. Auf diese Art und Weise nutze ich sowohl die perldoc als auch eigens entwickelte Utilities für RPC und FTP. Und natürlich liegen auch Perl~ wie PHPinterpreter auf Shortcuts, was die gerade geladene Datei dem Interpreter übergibt.

[ursus contionabundo]

Es geht ums Entwickeln, nicht um Präsentationen oder Schulungen.

Du hast gefragt:

Ja, aber warum sollte man sich das antun?

"Entwickeln" schließt ja nicht aus, dass man in einem Kurs "entwickelt", z.b. bei der Lösung kundenspezifischer Probleme.

• Weil manche IDEs auch nur Editoren mit Syntaxhervorhebung und einem Terminal sind.

Das soll ein Grund sein, wenigstens auf diesen Komfort zu verzichten?

Naja. Was, wenn man schon einen Editor mit Syntaxhervorhebung und ein komfortables Terminal (+ Browser mit Analysewerkzeugen, + tail -f fürs Error-Log) hat, deren Bedienung gewohnt ist und die "IDE" keinen darüber hinaus gehenden Mehrwert bietet?

Deshalb einen Editor vorzuziehen sehe ich keinen Sinn darin.

Schon klar. Aber die Übergänge zwischen "Editor" und "IDE" verwischen ziemlich stark. Normalerweise verwende ich übrigens Geany. Ich betrachte Geany aber eher als "Editor mit vielen Funktionen" und M$ VSC als "IDE"...

[dedlfix]

Tach!

Es geht ums Entwickeln, nicht um Präsentationen oder Schulungen.

Du hast gefragt:

Ja, aber warum sollte man sich das antun?

Auf die Frage "wer kann", nicht "wer muss". Dass es Gegebenheiten gibt, wo man keine IDE verwenden kann, spricht ja nicht grundsätzlich gegen deren Verwendung, wenn man dazu in der Lage ist. Und auch wer mag, soll doch bei den Werkzeugen bleiben, die demjeinigen genehm sind. Die ursprüngliche Frage war aber mit einem Unterton gestellt, dass wer IDEs einsetzt nur zu doof für Editoren mit wenig(er) Komfort ist.

dedlfix.

[ursus contionabundo]

Die ursprüngliche Frage war aber mit einem Unterton gestellt, dass wer IDEs einsetzt nur zu doof für Editoren mit wenig(er) Komfort ist.

Acho so. Das ist aber eine Idee, die mir so derart liegt, dass ich an diese Interpretation von PLs Frage nicht mal dachte. Mit IDE muss man nämlich mehr wissen und hat es dafür aber (wenn die übrigen Voraussetzungen stimmen) bequemer. Ein Glaube daran, das eine IDE Kenntnisse einer Programmiersprache oder gar Intelligenz ersetze, wäre ein offensichtlicher Irrglaube. Wer es es mit IDE kann kann es auch ohne. Eine Sprachreferenz sollte man in jedem Fall befragen können.

[pl]

Ohne eine eigene Idee oder dem Verständnis der Ideen anderer nützen weder IDE noch Editioren.

Mein Kunde hätte nie eine config.sys geschrieben wenn er die Idee die dahintersteckt nicht verstanden hätte.

.

[ursus contionabundo]

Mein Kunde hätte nie eine config.sys geschrieben wenn er die Idee die dahintersteckt nicht verstanden hätte.

Wozu das denn? Man kann DOOM I und II auch unter der grafischen Oberfläche von Windows 97 spielen. Sogar mit TCP/IP gegeneinander!

[pl]

Mein Kunde hätte nie eine config.sys geschrieben wenn er die Idee die dahintersteckt nicht verstanden hätte.

Wozu das denn? Man kann DOOM I und II auch unter der grafischen Oberfläche von Windows 97 spielen. Sogar mit TCP/IP gegeneinander!

Die Idee war: Windows 95 zu installieren. Ohne config.sys kein CD Laufwerk, ohne CD Laufwerk kein Windows 95. Und die Idee des Kunden war, seine CD's mit dem Computer abzuspielen.

So einfach ist das manchmal. Sogar ohne TCP/IP.

[TS]

Hello,

Acho so. Das ist aber eine Idee, die mir so derart liegt, dass ich an diese Interpretation von PLs Frage nicht mal dachte. Mit IDE muss man nämlich mehr wissen und hat es dafür aber (wenn die übrigen Voraussetzungen stimmen) bequemer. Ein Glaube daran, das eine IDE Kenntnisse einer Programmiersprache oder gar Intelligenz ersetze, wäre ein offensichtlicher Irrglaube. Wer es es mit IDE kann kann es auch ohne. Eine Sprachreferenz sollte man in jedem Fall befragen können.

Also OOP ohne IDE ist schon ganz schön heftig. Von der Assemblerschicht aufwärts alles selber zu gestalten ist wirklich ein Knüppeljob. Und selbst dann muss man noch eine Menge über Steuerregister, IVT, LDT, GDT , ..., Messaging, Signale, usw. der jeweils angepeilten Plattform wissen, um die Objectfiles ("Module") entsprechend vorbereiten zu können.

| Und genau diese Überlegung brachte mich dazu, mal für das Thema "Exceptions" einen Erklärbärwettbewerb auszurufen! |

Mein Angebot steht deshalb bis Ende des nächsten Jahres (31.12.2019!), und ich hoffe, dass sich da noch einige mit einem €-10er oder mehr als Sponsor anschließen. Wir können ja auch (Erster Preis 1x), (Zweiter Preis 2x), (Dritter Preis 3x) daraus machen. Wenn Ihr damit einverstanden seid, würde ich die Fachpresse über den Wettbewerb informieren - ganz nach dem Motto:

Die Energie des Verstehens

Und ich wünsche mir zu Weihnachten, dass sich alle Stammposter ihre Antworten vorher genauer überlegen, als leider z. Zt. üblich!

Glück Auf
Tom vom Berg

[pl]

Hello,

Also OOP ohne IDE ist schon ganz schön heftig.

Manchmal möchte ich nicht wissen was manche unter OOP verstehen.

MfG

[Camping_RIDER]

Aloha ;)

Also OOP ohne IDE ist schon ganz schön heftig. Von der Assemblerschicht aufwärts alles selber zu gestalten ist wirklich ein Knüppeljob. Und selbst dann muss man noch eine Menge über Steuerregister, IVT, LDT, GDT , ..., Messaging, Signale, usw. der jeweils angepeilten Plattform wissen, um die Objectfiles ("Module") entsprechend vorbereiten zu können.

Ein Texteditor ist keine IDE und trotzdem benötigt man manchmal nicht mehr als selbigen, um objektorientiert zu programmieren. Ich verstehe nicht, inwiefern die Nichtnutzung einer IDE dazu führt, dass man „von der Assemblerschicht aufwärts alles selber“ gestalten muss?

Vielleicht unterscheidet sich ja unsere Definition von IDE.

Grüße,

RIDER

[1unitedpower]

Mein Angebot steht deshalb bis Ende des nächsten Jahres (31.12.2019!), und ich hoffe, dass sich da noch einige mit einem €-10er oder mehr als Sponsor anschließen. Wir können ja auch (Erster Preis 1x), (Zweiter Preis 2x), (Dritter Preis 3x) daraus machen. Wenn Ihr damit einverstanden seid, würde ich die Fachpresse über den Wettbewerb informieren

Das ist ja deine Privatsache, kannst du also machen wie du möchtest. Oder möchtest du das im Namen des Vereins machen? Dann möchte ich dich bitten, das im Vereinsforum erst abzustimmen.

[beatovich]

hallo

• Weil der Beamer nur 1024x768px liefert.
• Weil 3(2) Kurstage für /P[a-z]{2-5}/-Grundlagen(Fortgeschritten) + IDE zu kurz sind.
• Weil manche IDEs auch nur Editoren mit Syntaxhervorhebung und einem Terminal sind.
• Weil manche IDEs natürlich an der fehlenden Umgebung für die Skripte scheitern (z.B. fehlt in PHP $_SERVER) und das Debugging dann doch anders gemacht werden muss.
• Weil die Position von ALT und TAB den Fingern bekannt sind.

Andererseits fummle ich hier gerade (unter Linux) mit mit M$ Visual Code herum und freue mich darüber, dass der beim Tippen hilft:

wenn auch etwas merkwürdig... aber das spart manchmal den Blick in die Referenz.

Ich habe kürzlich meine erste wirkliche Kundensite vollständig in meinem Javascript-Editor Modul entwickelt, der nichts anderes als ein Spezial-Purpose-Editor ist, der auch dem Kunden ausgeliefert werden soll.

Was nützt mir die tollste Arbeitsumgebung, wenn

• niemand damit umgehen kann
• diese nicht verfügbar ist
• diese zwar Syntax-Highlighting kann, aber doch keine Ahnung von HTML hat.

[Rolf B]

Hallo pl,

bis 1995 war meine Entwicklungsumgebung ein Editor ohne jegliches Intellisense und ein Batchfile für den Compiler+Link. Sprache: dBase (Clipper).

Immerhin gab es dort irgendwann Sourcelevel Debugger, das war eine Offenbarung.

Dann musste ich mich ein paar Jahre mit Smalltalk herumärgern, bis wir fusioniert wurden und endlich Visual Studio.net ins Spiel kam.

COBOL Programme auf dem IBM Host werden bis heute per Stupid-Edit und Compiler-Batch erstellt. Immerhin gibt's mittlerweile dort auch Sourcelevel Debugger.

PHP habe ich anfangs auch nur mit Notepad und Debug-Echos gebaut.

Heute ohne IDE ein C# Programm schreiben... Nein, könnte ich nicht. Ich könnte sicherlich ein Compile- oder Unittest-Script für ein C# Projekt bauen. Ich könnte ohne Intellisense editieren. Aber ich will nicht 😰

Rolf

[pl]

Natürlich ist das eine Frage der Gewohnheit. Auch wenn ich mit dem vi begonnen habe meine ersten c-Programme zu schreiben und auch später ungezählte Perlscripts mit vi und emacs entwickelte, konnte ich mich nie mit diesen Editoren anfreunden.

[Rolf B]

Hallo TS,

erklären kann ich dazu ein paar Sachen, auch ohne Recherche. Für Wiki-Level würde ich noch ein paar Sachen nachlesen.

Die Abläufe in einer interpretierten Umgebung sind aber jedenfalls anders als in einer compilierten.

Bei (in Maschinensprache) compilieren Programmen können dann auch noch Betriebssystem-Eigenheiten dazu.

Rolf

[TS]

Hello,

erklären kann ich dazu ein paar Sachen, auch ohne Recherche. Für Wiki-Level würde ich noch ein paar Sachen nachlesen.

Die Abläufe in einer interpretierten Umgebung sind aber jedenfalls anders als in einer compilierten.

Bei (in Maschinensprache) compilieren Programmen können dann auch noch Betriebssystem-Eigenheiten dazu.

Genau ;-)

Die Zusammenhänge sind mir übrigens so einigermaßen bekannt und ich vermute, dass hier noch keiner die totale Tragweite meines Aufrufes realisiert hat. Ich bin aber selber nicht in der Lage, meine privaten Erkenntnisse in der passenden Fachsprache nebst Erläuterungen wiederzugeben.

#@ALL:
Also seht es doch mal positiv und macht einfach mit, Wege zum Verständnis zu ebnen, ohne ständig Gründe dagegen zu suchen :-)

Glück Auf
Tom vom Berg

[pl]

Die erste Frage betreff Verständnis ist, was IDEs mit Exceptions zu tun haben sollen.

[TS]

Hello,

Die erste Frage betreff Verständnis ist, was IDEs mit Exceptions zu tun haben sollen.

Die IDE sollte alle Module des Systems kennen und passend kombinieren:

• Projektverwaltung
• ...
• Darstellung in der gewünschten Progammiersprache
• Quelltext
• Librairies
• ...
• Objektfiles
• Assembler-Ebenen für die unterschiedlichen Zielplattformen
• Linkerstrategien
• ...
• die tiefsten Tiefen der Register und UEFI-Module
• ...

usw.

Das möchte man nun wirklich nicht mehr alles eigenhändig verwalten, oder?

Glück Auf
Tom vom Berg

[pl]

Das möchte man nun wirklich nicht mehr alles eigenhändig verwalten, oder?

Und was hat die Verwaltung mit Exceptions zu tun?

[ursus contionabundo]

Das möchte man nun wirklich nicht mehr alles eigenhändig verwalten, oder?

Und was hat die Verwaltung mit Exceptions zu tun?

Ganz einfach: Wenn man beim Verwalten der Exceptions was falsch macht kommt sowas raus.

[pl]

Das möchte man nun wirklich nicht mehr alles eigenhändig verwalten, oder?

Und was hat die Verwaltung mit Exceptions zu tun?

Ganz einfach: Wenn man beim Verwalten der Exceptions was falsch macht

Exceptions werden nicht verwaltet!

Btw., ich lese hier immer wieder, daß catch dazu dient, Exceptions zu fangen. Das ist jedoch auch nicht richtig, denn gefangen wird eine Exception im try{}Block wobei man das besser als ein Auffangen bezeichnen sollte.

So ist das was in catch gemacht wird in erster Linie ein Lookup: Nämlich ob Exceptions gefallen und aufgefangen worden sind.

Mitnichten also werden Exceptions verwaltet, das ist völliger Unfug!

[Camping_RIDER]

Aloha ;)

Btw., ich lese hier immer wieder, daß catch dazu dient, Exceptions zu fangen. Das ist jedoch auch nicht richtig, denn gefangen wird eine Exception im try{}Block wobei man das besser als ein Auffangen bezeichnen sollte.

Nein, im try-Block fängt man sie sich ein.

So ist das was in catch gemacht wird in erster Linie ein Lookup: Nämlich ob Exceptions gefallen und aufgefangen worden sind.

Auch nein, denn würde schon der try-Block die Exceptions auffangen, dann könnten Sie später im Fall der Nichtbeachtung nicht weiter fallen. Deshalb ist das schon völlig richtig, dass erst der catch-Block die Exceptions fängt (und dann eventuell bewusst weiterwirft).

Gerade in typisierten Sprachen mit Vererbung von der Exception-Klasse kommt das zum Tragen, da ein Catch-Block nicht nur alle Fehler fangen, sondern auch nur eine einzige Art Fehler fangen kann.

Mitnichten also werden Exceptions verwaltet, das ist völliger Unfug!

Wer Code verwalten kann, kann auch Exceptions verwalten.

Häng dich doch nicht immer so an einzelnen Worten auf – vor allem dann nicht, wenn du im Zweifelsfall der bist, dessen Vorstellung davon, was die Wörter bedeuten, mit dem, was gefühlt alle anderen darunter verstehen, auseinandertriftet... Außer, du möchtest in Zukunft nur noch Selbstgespräche führen, dann kannst du dir natürlich weiter die Begriffe so zurechtlegen wie du lustig bist.

Grüße,

RIDER

[Rolf B]

Hallo,

im Hochsprachenkonstrukt try / catch kann man durchaus sagen, dass die Exception irgendwo geworfen und von den catch-Blöcken gefangen wird. Je nachdem, was die Catch-Blöcke dann tun, wird die Exception verschluckt, weitergeworfen (rethrow) oder durch eine neu geworfe Exception ersetzt.

Kurzer Regress zu dem, was ich über Perl gelernt habe: Wenn ich in Perl Exceptions fangen will, implementiere ich das so, dass ich den Code in eine eval-Klammer lege. Die Eval-Klammer fängt die Exception und stellt mir den geworfenen Wert in $@ bereit. Hier ist die Aufgabenteilung also anders: eval() macht die ganze Arbeit und danach kann der Programmierer die Trümmer begutachten.

Aber - das ist alles Highlevel und eine Abstraktion dessen, was auf Betriebssystemebene passiert. Schon das Wort Betriebssystem lässt erkennen, dass es jetzt spezifisch wird - jedes Betriebssystem anders. Übrigens sind 32-bit Windows und 64-bit Windows zwei unterschiedliche Betriebssysteme!

Win32: Jeder Windows Thread verfügt über einen Thread-Informationsblock (TIB), der an der Adresse FS:0 zu finden ist (ja, die guten alten Segmentregister). Der erste Eintrag des TIB ist ein Zeiger auf eine EXCEPTION_REGISTRATION Struktur aus zwei DWORDs: Ein Previous-Pointer (auf eine ältere Exception-Registration) und eine Prozedur-Adresse. Diese Struktur liegt nicht irgendwo, sondern auf dem Stack, im Stackframe der Procedure die einen try-Block aufbauen will. Wenn eine Exception geworfen wird (Win23 API Funktion), folgt Windows der Liste der registrierten Exceptionhandler und ruft den Callback auf. Der bekommt einige Informationen zur Exception und kann sagen: "Kann ich behandeln" oder "Lass fliegen". Sagt er "kann ich behandeln", wird die Handlerkette nochmal aufgerufen, diesmal mit einem "Unwind" Parameter. Das ist die Aufforderung für die Handler, eventuell fällige Aufräumarbeiten durchzuführen. Der Handler, der "kann ich behandeln" sagt, legt dann fest, wo die Programmausführung weitergeht und wie der Stackpointer zu justieren ist, damit der Code so weiterlaufen kann als wäre nichts geschehen. Das ist nicht trivial, ich habe es auch noch nie selbst gemacht, Microsoft hat es mies dokumentiert und die beiden Texte im Netz, die dazu was beschreiben, habe ich nur partiell verstanden 😀.

Win64: funktioniert ganz anders, da wird nichts auf den Stack gelegt. Weil - ein Buffer Overrun könnte das manipulieren oder zerstören. Statt dessen erzeugt man im EXE eine spezielle Steuertabelle, in der steht, in welchem Programmbereich welche Exceptionregeln gelten sollen (ich habe aufgehört, das genauer durchdringen zu wollen) und Win64 baut daraus den Stack Unwind selbsttätig zusammen. Vorteil ist, dass man Null Overhead hat um einen try-Block zu markieren. Ob man in einem try-Block ist, wird erst geprüft wenn die Exception fliegt.

Außer dem Structured Exception Handling (das es schon in Win95 gab) existiert seit WinXP noch Vectored Exception Handling - damit kann man einen zentralen Handler für alle Exception hinterlegen.

All das sind Informationen für Compilerbauer und Assemblerprogrammierer. Microsoft dokumentiert das deshalb so schlecht, weil man das gar nicht selbst nutzen soll. Auf Assemblerebene ist das alles eher simpel und frei von OOP: Man registriert einen Exception Handler, führt Code aus und nimmt den Handler wieder weg. Falls Betriebssystem oder eigener Code entscheiden, dass jetzt eine Exception fällig ist, wird RaiseException() aufgerufen und diese Funktion bekommt einen Exception Code, ein paar Flags und eine Liste von frei definierten Parametern übergeben. Im Handler kann man Code, Flags und Parameter abfragen. Die Laufzeitumgebung einer Hochsprache fügt hier ihre eigene Logik ein, um Destruktoren von Objekten auf dem Stack aufzurufen und Dinge wie Exception-Objekte zu erzeugen. Damit so etwa wie ein sauberer Stacktrace möglich ist, braucht eine Hochsprache außer der EXCEPTION_REGISTRATION noch ein paar Informationen mehr, um zu wissen wo genau der Stackframe beginnt, so dass außer dem Handler-Walk auch ein Stack-Walk möglich ist um den Stacktrace aufzubauen.

Und was machen Perl oder PHP? Die compilieren ihre Programme nicht in Maschinencode. Sie übersetzen Sourcecode in einen Zwischencode und interpretieren den. Wie von PHP ein try-Block aufgebaut wird, habe ich allerdings nicht durchschaut, es gibt in der ZEND-Engine keinen Opcode dafür (nur für throw und catch). Im PHP Wiki ist das auch nicht dokumentiert. Es ist hier also schwierig für jemanden, der in der ZEND Engine die Bits nicht beim Vornamen kennt, hier durchzublicken. Ich würde allerdings vermuten, dass PHP auch in der Windows Implementierung nicht das SEH von Windows verwendet, sondern sein eigenes Süppchen kocht.

Rolf

[Camping_RIDER]

Aloha ;)

im Hochsprachenkonstrukt try / catch kann man durchaus sagen, dass die Exception irgendwo geworfen und von den catch-Blöcken gefangen wird. Je nachdem, was die Catch-Blöcke dann tun, wird die Exception verschluckt, weitergeworfen (rethrow) oder durch eine neu geworfe Exception ersetzt.

Eben. Genau das war doch meine Aussage.

Grüße,

RIDER

[TS]

Hello Rolf,

hier wird es langsam spannend!

Du bist mMn im Moment der führende Erklärbär, auch wenn noch viele Details fehlen ;-)

Ich akzeptiere die Antwort daher schon mal [der Haken ist leider nicht verfügbar?!] und gebe ein (+), bitte aber um Verständnis, dass das angepeilte Ziel noch weit entfernt ist :-)

Ich würde es deshalb begrüßen, wenn Du die Neugierigen unter uns (z. B. mich) weiterhin begleiten und unterstützen würdest.

Glück Auf
Tom vom Berg

[Camping_RIDER]

Aloha ;)

[...] ich vermute, dass hier noch keiner die totale Tragweite meines Aufrufes realisiert hat.

Da hast du völlig Recht, hab ich nicht. Deshalb ja meine Nachfragen, auf die du bislang nicht eingegangen bist.

Positiv zu denken hat mich im übrigen bisher da auch nicht zur Erkenntnis geleitet.

Du musst mir das aber auch nicht erläutern, wenn du nicht möchtest.

Grüße,

RIDER

[TS]

Hello,

[...] ich vermute, dass hier noch keiner die totale Tragweite meines Aufrufes realisiert hat.

Da hast du völlig Recht, hab ich nicht. Deshalb ja meine Nachfragen, auf die du bislang nicht eingegangen bist.

Positiv zu denken hat mich im übrigen bisher da auch nicht zur Erkenntnis geleitet.

Du musst mir das aber auch nicht erläutern, wenn du nicht möchtest.

Ich möchte gerne.

Wie lauten die Fragen? Habe ich die tatsächlich übersehen? Das will ich gerne wieder gutmachen...

Glück Auf
Tom vom Berg

[Camping_RIDER]

Aloha ;)

Positiv zu denken hat mich im übrigen bisher da auch nicht zur Erkenntnis geleitet.

Du musst mir das aber auch nicht erläutern, wenn du nicht möchtest.

Ich möchte gerne.

Sehr gut 😀

Wie lauten die Fragen? Habe ich die tatsächlich übersehen? Das will ich gerne wieder gutmachen...

Ich hatte mich gefragt, wo der praktische Mehrwert liegt oder ob es sich um rein akademisches Interesse handelt.

Grüße,

RIDER

[TS]

Hello,

Wie lauten die Fragen? Habe ich die tatsächlich übersehen? Das will ich gerne wieder gutmachen...

Ich hatte mich gefragt, wo der praktische Mehrwert liegt oder ob es sich um rein akademisches Interesse handelt.

Ich will es gar nicht so hoch aufhängen "akademisches Interesse", sondern möchte den Ball flach halten und es "technisches Interesse" nennen. Wie wird es in der Praxis abgehandelt bis hin zur untersten Schicht...

Als "akademisch" würde ich es nur dann bezeichnen, wenn wir uns an keiner konkreten Sprache orientieren dürfen und/oder alle Schichten streng kategorisiert werden müssten, usw.

Glück Auf
Tom vom Berg

[Camping_RIDER]

Aloha ;)

Ich will es gar nicht so hoch aufhängen "akademisches Interesse", sondern möchte den Ball flach halten und es "technisches Interesse" nennen. Wie wird es in der Praxis abgehandelt bis hin zur untersten Schicht...

Als "akademisch" würde ich es nur dann bezeichnen, wenn wir uns an keiner konkreten Sprache orientieren dürfen und/oder alle Schichten streng kategorisiert werden müssten, usw.

Ich meinte das sprichwörtliche akademische Interesse und wollte damit keinen fachlichen Gütegrad festlegen 😂

Also im Sinne von: Ist das Thema von Interesse, weil es an sich eben interessant ist, oder hat man direkte/praktische Vorteile davon, darüber Bescheid zu wissen?

Grüße,

RIDER

[ursus contionabundo]

Als Diskussionsgrundlage von oben nach unten:

• Eine shell (die NICHT unbedingt ein "Kommandzeilenetwas" ist) startet Prozesse. Als Elternprozess selbst verläuft diese nicht fehlerhaft wenn ein Kindprozess fehlerhaft verläuft. Eine Shell selbst ist Kind- oder Enkelprozess eines Steuerprogramms eines OS (z.B. initd/systemd unter Linux), welches selbst nur vom Kernel verwaltet wird.

• Ein Compiler/Interpreter untersucht den Quelltext auf Syntaxfehler, manche (Compiler müssen das ja tun) auch auf Aufrufe fehlender Funktionen bzw. Klassen, manche also auch schon auf die Existenz der Libs (z.b. Klassendateien) und signalisiert diese. Der Elternprozess selbst verläuft hier nicht fehlerhaft, der Kindprozess (Compiler/Interpreter) bricht aber ab.

• Wird das Kompilat in einer "VM" ausgeführt (wie Java) werden Laufzeitfehler an diese gemeldet. Der Elternprozess (VM) selbst verläuft hier nicht fehlerhaft, der Kindprozess bricht aber ab.

• Wird das Kompilat eines Compiler/Interpreters direkt vom Compiler/Interpreter ausgeführt, dann werden Laufzeitfehler an den Elternprozess (eben der Kompiler/Interpreter) gemeldet. Auch hier verläuft der Elternprozess nicht fehlerhaft, der Kindprozess bricht aber ab.

• Ist das Kompilat stand-alone ausführbar, dann fügt der Compiler beim Kompilieren eine Fehlerbehandlung hinzu. Die kann "hart codiert" werden oder durch Verlinken von libs (-> .dll, "dynamic link libary" (win); -> .so, "shared object" (linux) ) Die Routinen liefert also die libarys der Sprache. Auch hier verläuft der Elternprozess (z.B. die Shell!) nicht fehlerhaft, der Kindprozess bricht aber ab.

• Im Assembler-Programm können Befehle zu unmöglichen oder unerlaubten Aktionen führen, z.B. dem Versuch, Daten in/aus nicht erlaubten Speicherbereichen zu pooken oder zu peeken. Auch muss der Assembler bekannte und erlaubte Befehle vom Rest zu unterscheiden wissen. Fehler werden über Interrupts gehändelt. Werden Assemberprogramme ausgeführt und sind fehlerhaft, dann verläuft der Elternprozess (der Assembler selbst) nicht fehlerhaft, der Kindprozess bricht aber ab.

Bis hierher sind die Elternprozesse immer in der Lage den Fehler des Kindprozesses an den eigenen Elternprozess weiterzumelden , bzw. sollen dazu in der Lage sein. Sind sie es nicht ergibt sich manchmal ein Bluescreen. Bluescreens treten besonders dann auf, wenn ein Prozess, der keinen Elternprozess hat, einen Fehler hat oder nicht abfangen kann.

• Bei erkannten Fehlern auf echter Prozessorebene tritt der letzte Satz des vorherigen Absatzes automatisch in Kraft. Manche enden aber nicht in einem Abbruch sondern mit falschem Ergebnis.

Wie wird es in der Praxis abgehandelt bis hin zur untersten Schicht...

Wenn Du es NOCH genauer wissen willst grenze Deine Frage ein.