Solidity – Why Do Throw and Revert() Create Different Bytecodes?

All gas is consumed because the EVM essentially only has 1 exception: Out of Gas.

To see this clearer, take a look at the difference between a "pure" exception, and an error due to bad/buggy/invalid EVM code. Out of Gas is the former. Now there are errors such as stack underflow, invalid JUMP, and invalid opcode: they can be called "exceptions" but they are more like errors than an EVM exception, because the developer of the contract has not written valid EVM code according to the rules of the EVM. For example, an invalid opcode is like writing "class" instead of "function" in Javascript: native Javascript does not have "class", unlike a language like Java. With stack underflow, it's like the developer telling the EVM to add 2 numbers, but the developer does not provide the 2nd number.

Note also how "exception" in the EVM, is different from other languages. For example, there is no divide by zero exception in the EVM (though Solidity 0.4+ will generate an exception for this). Assuming valid EVM code, there are no exceptions except for Out of Gas.

Since there's only an Out of Gas exception, these other errors were made to behave as Out of Gas. This is relatively consistent with some Ethereum design principles of generalization and minimizing complexity. In other words, when implementing the behavior of stack underflow, invalid JUMP, and invalid opcode, it's simpler and easier for the protocol to reuse the implementation and behavior of Out of Gas.

Other answers have explained how Solidity compiles throw to an invalid JUMP. (Serpent instead uses an invalid opcode, and calls it invalid instead of throw.)

EDIT: The Byzantium release includes EIP 140, a new opcode named REVERT in the EVM that:

provides a way to stop execution and revert state changes, without consuming all provided gas and with the ability to return a reason.

throw is being deprecated in favor of revert(), require(), assert()

There are two aspects to consider when choosing between assert() and require()

1. Gas efficiency
2. Bytecode analysis

1. Gas efficiency

assert(false) compiles to 0xfe, which is an invalid opcode, using up all remaining gas, and reverting all changes.

require(false) compiles to 0xfd which is the REVERT opcode, meaning it will refund the remaining gas. The opcode can also return a value (useful for debugging), but I don't believe that is supported in Solidity as of this moment. (2017-11-21)

2. Bytecode analysis

From the docs (emphasis mine)

The require function should be used to ensure valid conditions, such as inputs, or contract state variables are met, or to validate return values from calls to external contracts. If used properly, analysis tools can evaluate your contract to identify the conditions and function calls which will reach a failing assert. Properly functioning code should never reach a failing assert statement; if this happens there is a bug in your contract which you should fix.

The above excerpt is a reference to the still (as of 2017-11-21) experimental and undocumented SMTChecker.

I use a few heuristics to help me decide which to use.

Use require() to:

• Validate user inputs
• Validate the response from an external contract
  ie. use require(external.send(amount))
• Validate state conditions prior to executing state changing operations, for example in an owned contract situation
• Generally, you should use require more often,
• Generally, it will be used towards the beginning of a function.

Use assert() to:

• check for overflow/underflow
• check invariants
• validate contract state after making changes
• avoid conditions which should never, ever be possible.
• Generally, you should use assert less often
• Generally, it will be use towards the end of your function.

Basically, assert is just there to prevent anything really bad from happening, but it shouldn't be possible for the condition to evaluate to false.

Historical note:

The require() and assert() functions were added to Solidity prior to the Byzantium fork, in v0.4.10. Prior to Byzantium, they behaved identically, but already compiled to different opcodes. This meant that some contracts deployed before Byzantium behaved differently after the fork, the main difference being that began refunding unused gas.