Guten Morgen

ich bin auf der suche um mein programm nicht abschmieren zu lassen... das tut es leider wenn ich einen datensatz eintragen will bei dem die spalte HardwareID bereits mit z.b xyuz vergeben ist und ich nochmal xyzu eintragen will...

kann wie kann ich das ganze abfangen und als fehlermeldung darstellen ?

mfg

try/catch

MSDN

oder das hier

Try/Catch sollte man meiden soweit es geht.
Frag einfach ab (zB per IF) bevor du den Datensatz einfügen willst ob bereits was in dieser Spalte steht.

lg

naja - das ist halt ein Fehler, den Datensatz xyzu ein zweites mal hinzufügen zu wollen - da solltest du froh sein, dass dein Prog das ablehnt, und du solltest dich fragen: "wie kommt es dazu, dass ich denselben Datensatz zweimal zufügen möchte?"

Try/Catch sollte man meiden soweit es geht.

Wie kommstn darauf?

Weil Try-Catch ausgelöst wird wenn ein Fehler im Programm vorliegt. Das heißt es sollte etwas ausgeführt werden, kann aber nicht und das Programm lauft weiter.

Try-Catch sollte eigentlich nur dann verwendet werden wo man es einfach nicht vorausplanen kann, dass die FUnktion seinen Zweck erfüllt (Bsp.: Dateidownload aber Inet grad nicht da). Aber hier kann man das mit normalen IF-Anweisungen abfragen.

lg

Hmm jeder hat seine eigene Meinung dazu.
Ich verwende den Try/Catch block überall da wo am wahrscheinlichsten ein Fehler auftauchen könnte und damit man weiß was der Fehler ist.

Natürlich nicht für jeden kleinen Code.

Bsp.: Dateidownload aber Inet grad nicht da

Da braucht man auch nicht unbedingt nen Try/Catch, man kann auch die Internetverbindung überprüfen bevor man versucht was runterzuladen aber wie gesagt es ist jedem selbst überlassen, Fakt ist das man beides machen kann aber nicht sagen 'Ich rate davon ab'

Svenley schrieb:

Ich rate davon ab

Sagte ich auch nicht

Nur ich setze es einfach nur da ein, wo man, sagen wir einfach mal, keine "Macht" dazu hat, es zu steuern.
Inet Verbindung prüfen ohne Try/Catch wüsste ich jetzt zB mal nicht wie das geht.

lg

Svenley schrieb:

Hmm jeder hat seine eigene Meinung dazu.

und ich unterstehe mich, zu behaupten: Manche Meinungen sind halt korrekt, und manche sind Stuss

Ich verwende den Try/Catch block überall da wo am wahrscheinlichsten ein Fehler auftauchen könnte und damit man weiß was der Fehler ist.

Das erreichst du am besten, wennde den TryCatch wegläßt.
Weil wenn ein Fehler auftaucht, klopft dir die IDE auf die Finger, mit einer Präzision, die einfach unübertrefflich ist. Das ist bereits die Voreinstellung, wenn man garnet erst anfängt mitte TryCatcherei.
Man ist echt deppert, wenn man sich das selbst wegnimmt, indem man es per TryCatch unterdrückt.

Aber selbst in einer Release ist TryCatch ein heißes Eisen, an dem man sich nur zu leicht die Finger verbrennt - gugge AvoidTryCatch

wie mach ich am besten eine if abfrage ?

so?





oder gibts was kürzeres ?

Damit müsste es gehen musst halt nur den Reader Deklarieren

naja - mit DateReadern zu arbeiten ist eh - nett gesagt: suboptimal.

Du kannst die datensätze in eine DataTable laden - du mußt sie ja eh laden - warum nicht in eine Datatable?
und wenn du dataTables verwendest, dann kannst du ja nachgucken, ob du einen Datensatz schon hast - dafür brauchts keine extra-Abfrage an die DB.

Btw: du hast den Datensatz und veränderst ihn, oder du hast ihn nicht, und fügst einen neuen hinzu.
Ein DataAdapter, wenn er Updated, erkennt automatisch, ob es sich um einen bereits bestehenden handelt, oder um einen neu zugefügten - und produziert (und ruft es auf) auch gleich das korrekte Update- oder Insert-Command.

gugge "Datenbank in 10 Minuten" auf Movie-Tuts

(ein Problem der Datenbänkerei nach ADO ist, dasses einfacher ist, als man sich vorstellen kann (insbesondere, wenn man sich vom Galileo-Openbook hat verwirren lassen))

ErfinderDesRades schrieb:

Svenley schrieb:

Hmm jeder hat seine eigene Meinung dazu.

und ich unterstehe mich, zu behaupten: Manche Meinungen sind halt korrekt, und manche sind Stuss

Ich verwende den Try/Catch block überall da wo am wahrscheinlichsten ein Fehler auftauchen könnte und damit man weiß was der Fehler ist.

Das erreichst du am besten, wennde den TryCatch wegläßt.
Weil wenn ein Fehler auftaucht, klopft dir die IDE auf die Finger, mit einer Präzision, die einfach unübertrefflich ist. Das ist bereits die Voreinstellung, wenn man garnet erst anfängt mitte TryCatcherei.
Man ist echt deppert, wenn man sich das selbst wegnimmt, indem man es per TryCatch unterdrückt.

Aber selbst in einer Release ist TryCatch ein heißes Eisen, an dem man sich nur zu leicht die Finger verbrennt - gugge AvoidTryCatch

Ja manche Meinungen sind wirklich Stuss...
Wenn man als Beispiel jetzt mit ner Funktion auf eine Datei zugreifen und bspweise löschen, ändern o.ä.will, diese aber schreibgeschützt ist, verwende ich Try Catch und und in der Exception steht doch dran drin warum keine Operationen daran vorgenommen werden kann also erzähle mal keinen Unsinn vonwegen TryCatch ist für die Katz.

Wenn dein Prog versucht, geschützte Dateien unzulässig zu manipulieren, dann ists falsch programmiert - da hilft auch kein TryCatch.
Du musst den Fehler beheben, und dazu musste debuggen, und das geht am besten ohne TryCatch.

Es gibt natürlich Ausnahmen - vlt. programmierst du ja grade einen Dateibrowser.

ErfinderDesRades schrieb:

Wenn dein Prog versucht, geschützte Dateien unzulässig zu manipulieren, dann ists falsch programmiert - da hilft auch kein TryCatch.
Du musst den Fehler beheben, und dazu musste debuggen, und das geht am besten ohne TryCatch.

Es gibt natürlich Ausnahmen - vlt. programmierst du ja grade einen Dateibrowser.

Nicht unbedingt, kann doch sein das Du eine Datei beschreiben willst die gerade von einem anderen Programm oder vom System verwendet wird.
Jetzt nicht auf geschützte Systemdateien bezogen.

Oder wenn Du Registry Einträge verändern willst aber Dein Programm ohne Administratorrechte ausgeführt wird.


Und nein, ein Dateibrowser wirds nicht, zu simpel

wie gesagt: mir fällt kaum ein sinnvolles Programm ein, was man dazu bräuchte, um x-beliebige Dateien zu manipulieren (DateiBrowser habichja schon genannt).
Klar kannst du einen Editor proggen, und dann damit iwelche Exen im Windows-Verzeichnis öffnen und überschreiben. Aber dann fände ichs auch voll korrekt - und kein User wird sich drüber wundern - wenn das Proggi dann abstürzt, wenn mans so verwendet.

Und wenn dein Proggi an den System-Einstellungen rumschraubt, dann kannst du vlt (nicht immer, klar) von vornherein dafür sorgen, dasses mit Admin-Rechten gestartet werden muß.

Generell gilt: Die Fehlermeldungen sind nicht unsere Feinde, sondern sind unsere besten Freunde: weil sie melden uns die Fehler (wenn man sie läßt). Und Fehler muß man beheben, nicht behandeln.

Wie gesagt: gut durchdachte Ausnahmen sind gelegentlich nötig.
Aber man muß da wirklich jeden Einzelfall gut durch-denken - und dann findet man meist, dass ein TryCatch kontraproduktiv oder gar gefährlich ist (lieber eine App 20 mal abstürzen lassen, als einmal in instabilem Zustand weiterlaufen lassen)

ErfinderDesRades schrieb:

Das erreichst du am besten, wennde den TryCatch wegläßt.

Nein. Der Grund, warum das Net Framework so viele Exceptions schmeißt, ist, dass MS die Exceptions als "Nachricht" versteht und nicht als "Fehler". MS hätte ja auch das alte C-System wählen können: eine Funktion liefert 0, wenn alles ok war und einen Code, wenn ein Fehler auftrat.

s.auch
msdn.microsoft.com/en-us/libra…nal_errorhandling_methods

Exceptions offer several advantages over other methods of error notification, such as return codes. Failures do not go unnoticed. Invalid values do not continue to propagate through the system. You do not have to check return codes.

Wobei ich persönlich häufiger so was vorziehen würde wie in Google Go. Eine Funktion liefert halt ein Ergebnis UND eine Exception (kein Fehler = nothing)

Quasi:
Public Class Result(Of T)
Public Property Value As T
Public Property [Exception] As Exception = Nothing
End Class

Public Function Foo() As Result(Of Integer)
Return New Result() With {.Value = 9}
End Function

picoflop schrieb:

Nein. Der Grund, warum das Net Framework so viele Exceptions schmeißt, ist, dass MS die Exceptions als "Nachricht" versteht und nicht als "Fehler".

verstehe ich doch auch so: Eine Fehlermeldung ist die Meldung eines Fehlers.

Vlt. nehme ich diese Nachrichten ernster als andere, weil ich empfehle, sie als Nachricht an den Programmierer aufzufassen, nicht als Nachricht im Sinne des Programmflusses.
Und dass das FW so viele davon wirft, liegt halt an den unendlich vielen Möglichkeiten, in einem Programm unzulässige Zustände herzustellen.

Eine Rückmeldung, dass ein Vorgang nicht stattgefunden hat, wie etwa TryCast(bla, ZielTyp) oder Dictionary.TryGetValue() würde ich hingegen nicht als Meldung eines Fehlers auffassen, denn indem der Programmierer TryCast oder TryGetValue verwendet, richtet er seinen Programmfluß ja auf diese Möglichkeit ein.
(Tuterdas nicht, gibts sicher an der nächsten Ecke eine richtige Fehlermeldung )