Wie liest man Antworten von Aufrufen an Vertragsmethoden, die mit web3.js erstellt wurden?

Ich habe einen Vertrag erstellt, der eine einfache Methode zum Speichern einiger Daten in einer Eigenschaft meines Vertrags in der Blockchain bietet.

Ich kann mit web3.js eine Schnittstelle zu meinem Vertrag herstellen, und ich habe kein Problem damit.

Das Problem ist, dass ich nur in der Lage sein möchte, die Eigenschaft festzulegen, wenn sie noch NICHT festgelegt wurde . Als solche prüft die Contract-Methode auf einen Nullwert und gibt einen willkürlichen Fehlercode ("0001") zurück, wenn er bereits gesetzt wurde. Wenn es nicht gesetzt wurde, wird "0000" zurückgegeben.

Wenn ich die Methode (über Javascript) ausführe, wird mein Callback sofort aufgerufen. Das Ergebnis enthält den Transaktionshash für eine noch nicht geschürfte Transaktion. Wenn die Transaktion geschürft wird, gibt es keine weiteren Aufrufe des Rückrufs, und zu keinem Zeitpunkt wird der Fehlercode (oben erwähnt) asynchron in meinem Javascript-Code zur Verfügung gestellt.

Daher kann ich meine Schnittstelle nicht entsprechend aktualisieren, wenn ein "Fehler" vorliegt.

Ich kann den Transaktions-Hash abfragen und prüfen, an welcher Stelle er geschürft wird, aber da auch im Fehlerfall die Transaktion geschürft wird, nützt das wenig.

web3.js verliert viel von seinem Nutzen, wenn es keine Möglichkeit gibt, die Reaktion auf das Mining einer Transaktion in der Blockchain zu erkennen. Habe ich etwas verpasst?

Vielen Dank

Vermissen Sie Veranstaltungen? Hilft das ethereum.stackexchange.com/questions/765/… ?

Antworten (1)

Transactions gibt den Fehlercode nicht zurück, wie Sie sagen. Es wurde jedoch darüber gesprochen, dies zuzulassen.

Rückgabewerte für nicht konstante Funktionen sind wirklich nur bei Aufrufen von Vertrag zu Vertrag nützlich. Für externe Anrufe (dh Transaktionen) ist Events eine Lösung, oder manchmal könnten Sie es durch eine Kombination aus Transaktionen lösen, prüfen, wann tx abgebaut wird (oder nicht) und dann eine Form von Behauptung über den Vertragsstatus durchführen.

Ereignisse sind der einfachste Weg, um sicherzustellen, dass eine Transaktion zu einem bestimmten Ergebnis geführt hat.

Ereignisse können nach ID gefiltert werden, was bedeutet, dass Sie ein bestimmtes Ereignis zu einer bestimmten Funktion hinzufügen können, da Sie wissen, dass das Ereignis mit dieser ID ausgelöst wird, wenn dieser Code ausgeführt wird.

Ereignisse können auch nach dem Hash der Transaktion gefiltert werden, die das Ereignis generiert hat, was bedeutet, dass Sie eine Transaktion senden, den tx-Hash abrufen und diesen dann verwenden können, um nur die von dieser Transaktion generierten Ereignisse zu beobachten. Wenn es ein Ereignis mit diesem bestimmten Hash gibt, ist das ein Beweis dafür, dass die TX durchgegangen ist, und wenn die TX erfolgreich abgebaut wurde, aber kein Ereignisprotokoll erstellt wurde, dann ist sie sicherlich nicht durchgelaufen.

Davon abgesehen erhöhen Events die Benzinkosten, sind also nicht der effizienteste Weg und sollten nach Möglichkeit vermieden werden. Manchmal können Sie überprüfen, ob der TX abgebaut ist, und dann den Vertrag aufrufen, um zu sehen, ob er sich wie erwartet geändert hat. Unnötig zu erwähnen, dass dies nicht immer eine Option oder so sicher ist.

Übrigens, ich persönlich neige dazu, Ereignisse mit demselben Namen wie die Funktion zu verwenden, in der sie aufgerufen werden, außer dass der erste Buchstabe groß geschrieben wird. Außerdem geben sie alle einen „Fehler“-Parameter zurück (manchmal ist das der einzige Parameter), und Fehlercodes sind ebenfalls standardisiert, was es mir ermöglicht, standardisiertes Javascript für Transaktionen zu verwenden. Grundsätzlich: Funktion aufrufen -> Hash abrufen -> Ereignis mit demselben Namen wie Funktion abhören, aber erster Buchstabe groß geschrieben -> Fehlerparameter prüfen -> Rückruf mit Fehler, wenn Fehlercode != 0, sonst nicht.