Debugging/Tracing App <--> Contract interaction

So in Ethereum we have data that is traveling potentially through application code (like python) and that can then be sent through to a contract. I'm wondering how one goes about tracing requests through the system to include these layers. For example, when I send a transaction to an Ethereum contract, shouldn't I have different rejection codes (plus a success code) as I would have HTTP response codes in an http-based system? Seems like there are only disconnect codes in the wire protocol spec. Maybe contracts should allow some way to return a small message that can be customized? Such a return statement (and/or modification of STOP) would allow something significant to be sent in the returning TCP ACK that can be parsed at the application layer for logging/debugging purposes.

Comments

  • jw1jw1 Member Posts: 27
    Ok, that was weird, just saw this on today's blog entry:

    "A message call is an operation executed from inside a contract which takes a destination address, an ether value, and some data as input and calls the contract with that ether value and data, but which also, unlike a transaction, returns data as an output. There is thus also a new RETURN opcode which allows contract execution to return data."

    You guys are great!
  • aatkinaatkin Member Posts: 75 ✭✭
    Another potential debugging tool is to store contract state or variable values in contract.storage. They can then be easily viewed using etherchain.org. Simulators are also useful.

    I also try to compile all the paths through my contracts individually to get an estimate of ether cost. Then I plan to put them on the test chain so I know exactly how much GAS each execution path requires.
Sign In or Register to comment.