Ja, sagtest du schon.. aber unter D7 geht das bei EnumWindows nicht ohne "Incompatible Types"-Fehler, bei anderen
API's dagegen schon (z.B. "GetClassName"). Ist aber auch für dieses TinyTool nicht logisch. Wenn ich auf etwas prüfe, dann macht das ja wohl nur Sinn, wenn ich bei Negativ-Prüfung etwas anderes machen möchte oder anzubieten habe. In diesem Fall hab' ich nichts anzubieten und müßte das Programm schließen. Aber auch das ist quatsch, da sich das Programm ja binnen Sekundenbruchteilen selber schließt...
Deswegen sehe ich den Nutzen hier nicht... den ZusatzCode kann ich mir sparen...
Wobei ich ja gut finde, dass die
API keine
Exception wirft, aber ich kann nicht beurteilen ob das absolut in jedem Fall so ist und ich kann ebenfalls keine Performance-Nachteile erkennen, die durch TryExceptEnd entstehen. Geht mit und ohne brutal schnell... wo ist also der Nachteil? Sollte etwas außerhalb der
API's schief gehen, dann hab' ich's abgefangen...
Klar, wenn du eh keine Sinnvolle Aktion im Fehlerfall ausführen kannst, dann brauchst du natürlich nicht jeden
API Call prüfen.
Warum weglassen? Ist für ein kleines Projekt vielleicht halb so wild, aber je größer es wird, desto mehr sollte man Wurschtel-Code und unnötige Blöcke vermeiden. Vor allem kann ja zwischen den
API Aufrufen wirklich nichts fehlschlagen. Ich glaube du hast so bisschen die Vorstellung, dass einfach mal "zufällig" durch den Maschinencode irgendwo Exceptions fliegen können. Das ist aber nicht der Fall.