Internal Errors sind im Grunde Assertions, die niemals auftreten sollten (in etwa so wie eine nicht gehandelte
Exception in deinem Programm, die dem Endbenutzer entgegen kommt) und die Zahlen deuten auf die Stelle im Code hin und sind demnach für die Devs bei Emba nützlich um den Fehler zu finden.
Nichtsdestotrotz wäre eine Liste sehr hilfreich, in der zumindest grob drinsteht was an der Stelle abgefangen wird...
Dass das dann nicht immer zum Fehler führt und dass es nicht immer möglich ist viel zu einer solchen Codestelle zu schreiben, ist klar, aber zumindest bei einigen Fehlern wären sicher Hinweise möglich.
Reproduzierbare Fälle sind ja kein so großes Problem, die kann man melden, aber bei welchen, die nicht einmal auf anderen PCs mit dem gleichen Projekt reproduzierbar sind...
Es ist echt nicht lustig dann per Assembler und Process Monitor zu debuggen. Oft lässt es sich dann zwar lösen, aber es kostet extrem Zeit, wenn man nicht einmal einen Ansatz hat wonach man suchen könnte...
Wo wir gerade beim Compiler sind: An der Stelle wäre auch ein Debuglog interessant, in dem man sehen kann welche Dateien in welchen Pfaden in welcher Reihenfolge abgearbeitet wurden, damit man da nicht im Process Monitor suchen muss.
Zur einer "Dokumentation" zu den Internals hat Allen mal was gesagt und erwähnt, dass dies ein administrativer Overhead wäre, der nicht viel nützen würde. Die Info Build No + Internal Error No ist genug Information für die Devs.
Ich persönlich hatte noch nie einen nicht reproduzierbaren Internal, von daher kann ich nichts dazu sagen.
Zum Debugger Log kann ich nur zustimmen, das würde auch das reporten der Internals etwas vereinfachen. Denn wenn er wie bei dir mal nicht reproduzierbar ist, ist es schwer einen
QC zu erstellen, wenn man keine Beschreibung zum Reproduzieren geben kann. Vielleicht sollten sie madExcept oder EurekaLog in die dcc reinpacken
