Hallo,
Ich habe folgendes Problem:
Ich rufe eine .net dll-Funktion auf, welche eine Exception auswirft, wenn ich ihr ein 0 übergebe!
Diese Exception wird dann im Fehler-Cluster angezeigt (Mit dem Code 1172 und dem entsprechende Text, wie im Anhang).
Es ist nun so, dass die Exception ja eine Klasse ist, (in meinem Fall eine "DummyException").
Diese hat wieder Funkionen zur Verfügen, auf die ich zugreifen möchte.
Weiss jemand wie man an diese herankommt?
Besten Dank
Dani
Beispiele in LV2009
rolfk oder IchSelbst bestimmt.....
Gruß Markus
Vorab:
Exceptions sind Elemente, mit denen ich mich nicht befasse. Sie dienen zum Abfangen von unvorhersehbaren (das sind per se unvermeidbare Fehler) und unverhergesehenen (das sind per se vermeidbare Fehler, daher solche, die nicht auftreten sollten) Fehlern. Da ich letzteren Typ grundsätzlich vermeide, brauch ich Exceptions nicht, weder in LV noch in Delphi. Vermeiden geht ganz einfach: Vor der Division abfragen, ob der Divisor Null ist.
' schrieb:Es ist nun so, dass die Exception ja eine Klasse ist, (in meinem Fall eine "DummyException").
Ja. Da gebe ich dir recht.
Nur: Was willst du in LV auf Anwenderebene mit Exceptions? Du würdest dann einen Exceptionhandler brauchen, der aber in ein Datenflußprinzip nicht integrierbar wäre.
Wolltest du in einer tieferen Ebene irgendwas beeinflussen, z.B. das Generieren von Error(cluster)-Meldungen, - dann geht das aber schon ins Eingemachte. Sowas mach ich nicht mehr. RolfK kennt sich da bestimmt noch aus.
Zitat:Diese hat wieder Funkionen zur Verfügen, auf die ich zugreifen möchte.
Was ich von Delphi und seinen Exceptions so weiß, ist das nicht besonders viel, was so eine Exception-Class ausmacht. Wie du in LV oder gar .Net an die Methoden der Klasse kommst, weiß ich nicht. Und sowas wie ein OnException in LV auf Anwenderebene zu integrieren, ist bestimmt auch nicht trivial.
' schrieb:rolfk oder IchSelbst bestimmt.....
Gruß Markus
Sorry, nein. .Net versuche ich wann immer möglich zu vermeiden. Exceptions auf WinAPI Niveau habe ich grundsätzliche Kenntnisse aber auch nicht wirklich sehr ausführende und ich weiss absolut nicht ob .Net Exceptions intern auf WinAPI Exceptions aufbauen oder ob das ein grundsätzlich anderer Mechanismus ist. Ich denke jedenfalls dass das Abfangen von .Net Exceptions mit WinAPI Exception Mitteln so oder so fast nicht möglich ist, da .Net die WinAPI Exceptions garantiert auf irgendeine Weise wrapt so es sie dann überhaupt als unterliegenden Mechanismus verwendet.
Grundsätzlich denke ich dass man mit .Net Systemaufrufen wohl einen Exceptionhandler installieren kann der dann als .Net Event an ein LabVIEW Callback-VI übergeben wird. Selber bin ich aber genau so wie IchSelbst von Exceptions alles ausser begeistert. Es ist so oder so immer eine "After the fact" Behandlung von Fehlern und man hat eigentlich nur zwei Möglichkeiten dabei. Entweder handelt es sich um einen vorhersehbaren Fehler den man dann in der Exception mühsam wiederherzustellen versucht, oder es ist ein unvorhersehbarer Fehler und dann kann man ausser einem Dialog mit der Mitteilung dass es besser ist die Applikation zu beenden auch nicht wirklich viel tun. Bei vorhersehbaren Fehlern ist es aber viel effektiver um diesen Fehler gar nicht erst auftreten zu lassen.
Hallo,
Besten Dank für eure Informationen.
Mein System sieht so aus, dass unterhalb meiner .net dll mehrere Gerät angesprochen werden. (Es wird über RS232 kommuniziert)
Diese Geräte können in diverse Fehlerzustände kommen. Z.b. eine Übertemperatur.
Fehler also, die man nicht verhindern kann.
Die Idee ist, dass man das gesamte Fehlerhandling über Exception macht.
Die Exception sind in meinem Fall keine unvorhersehbare Fehler, sondern einfach Fehler die im System auftretten können.
(Gem. meinem Kollegen ist das in der C#/.net Welt so üblich, oder fast ein muss!)
Die Fehler sollen natürlich soweit wie möglich in der dll behandlet werden.
Das Beispiel der Übertemperatur soll jedoch an LabVIEW, (was nur ein GUI darstellt) weitergereicht werden.
So kann der Anwender darauf reagieren, in dem er z.B. das Gerät abschaltet.
Die Exception die in der Dll ausgeworfen wird, ist von der Klasse "Exception" abgleitet, und enthält noch zusätzliche Methonden.
Über dies kann man an weiter Informationen herankommen, wie zum Beispiel, welches Gerät hat den Fehler erzeugt, Zeit, Fehlernummer... u.s.w.
Wie ich aus euren Antworten herauslesen, ist es von LabVIEW (oder grundsätzlicht?) nicht so angedacht, dass man ein Fehlerhandlig mit Exceptions löst. Sondern eher, dass wenn man einen unvorhergesehen Fehler mit dem eigenen Fehlerhandlich nicht abgefangen hat,
man durch die Exception darauf aufmerksam gemacht wird um dies noch nachzuholen.
Besteb Dank!
Dani
' schrieb:Diese Geräte können in diverse Fehlerzustände kommen. Z.b. eine Übertemperatur. Fehler also, die man nicht verhindern kann.
Eine Übertemperatur ist kein Fehler, sondern ein Zustand, der
explizit beachtet werden muss. Eine Übertemperatur kann man mit ganz normalen Funktionen handeln.
Zitat:Die Exception sind in meinem Fall keine unvorhersehbare Fehler, sondern einfach Fehler die im System auftretten können.
Aber doch keine Fehler im System (z.B.) Klimaschrank !
Zitat:(Gem. meinem Kollegen ist das in der C#/.net Welt so üblich, oder fast ein muss!)
Naja, bisher programmiere ich nur in Win32 und in LabVIEW. Auch in Win32 könnte man Fehlerbehandlungen mit Exceptions machen. Ggf. würde das im Fehlerfall auch sehr einfach sein. Nur: Exceptions haben was von brachialer Gewalt. Damit kann man die ganze Unterprogramm-Hierarchie mit einem "Rücksprung" aushebeln. Sowas macht man einfach nicht.
Zitat:Wie ich aus euren Antworten herauslesen, ist es von LabVIEW (oder grundsätzlicht?) nicht so angedacht, dass man ein Fehlerhandlig mit Exceptions löst.
Ich bin der Meinung, dass man eine derartige Fehlerbehandlung grundsätzlich nicht mit Exceptions machen sollte.
Zitat:Sondern eher, dass wenn man einen unvorhergesehen Fehler mit dem eigenen Fehlerhandlich nicht abgefangen hat,
man durch die Exception darauf aufmerksam gemacht wird um dies noch nachzuholen.
Eher so.
Oder z.B. wenn plötzlich die serielle Schnittstelle als solche nicht mehr vorhanden ist.
Mir fällt noch was ein: Eine Exception kann man als "Selbstschutzmechnismus" auffassen. Würde das Ausführen einer Methode innerhalb eines Moduls unmöglich sein, so kann das Modul diese Situation mit einer Exception umgehen - sofern es nicht möglich ist, diese Sitiation nicht doch mit einer spezifischen Methode abzuarbeiten (z.B. einer entsprechenden Rückmeldung). Der Dividierbefehl z.B. muss eine Exception machen, wenn der Divisor Null ist: Durch Null darf er nämlich nicht teilen, Möglichkeiten der Fehlerrückmeldung hat er nicht.
Eigentlich ist es eher eine Philosophiefrage, wo man die Grenze zieht zwischen Exception (= nachlaufende Fehlerbehandlung) und eigener (vorlaufender) Fehlervermeidung.
Zum Schluss noch was:
Wenn du doch die Methoden (und Felder etc.) der Klasse ".Net-Exception" haben willst, warum fragst du dann in einem LabVIEW-Forum für LabVIEW-Anwender? Wäre da nicht ein .Net-Forum besser: Deine DLL soll ja die Exception in .Net machen/auswerten und daraus einen Error-Cluster für LV machen.
Wie schon eher angetönt denke ich dass man in LabVIEW durchaus .Net Exceptions machen kann. Man muss ganz einfach mit den System Services von .Net arbeiten die wohl sicher irgendwo die Exception Klasse verfügbar machen. Wahrscheinlich wird das so gehen dass man dann wenn so eine Exceptionklasse einmal geöffnet ist, man irgendwie ein .Net Event erhalten kann für bestimmte Exceptions und man dieses dann mittls .Net Eventcallback-VIs in LabVIEW empfangen kann.
Klingt jetzt alles ziemlich um x Ecken herum und ist es eigentlich auch, aber so funktionieren Exceptions nun einmal.