why evm sload with uninitialized data return zero value, not error?
I think maybe when reading uninit data, we can return error or panic in go?
What does that mean?
Can you give a coding example please?
It’s just how the EVM was designed. Storage, transient storage and memory are implicitly zero-initialized. Same with reading read-only memory areas past the end, like calldata, or contract code. The compiler relies on this for more efficient code. For example all push() (with no argument) has to do with storage is to update array length. No elements have to be actually zeroed, which matters a lot when array items are big.
The only case where EVM reverts if you touch the uninitialized parts is dealing with returndata, which is an inconsistency that actually makes optimization harder. If the opcode is not side-effect free the optimizer can’t freely remove it even if the result is never used. That’s because it’s usually not known at compilation time whether it will read past the end or not. If it just returned zeros, it could more easily be treated as no-op.
And that is why I asked what you meant by “uninitialized data”.
According to your own admission (above), there is no such thing on the EVM.
Not sure what you mean. Did you mistake me for the OP?
Yeah, I guess I did 
The question refers to “uninitialized data”, and I have asked for an elaboration on that, since AFAIK, there is no such thing in the given context.
I assumed that your answer was in response to that question of mine, and not in response to the original question.
Haha, no worries
And yeah, the question was not very precise. I just assumed it must be about storage, because I can’t see any other way it would make sense.
Well, the “sload” in the question does indeed imply that it is about storage.
But regardless, every variable is initialized to 0 (i.e., to “the 0 of the variable’s type”).
And that’s regardless of the variable location - storage, memory or stack… right?
So either way, the term “uninitialized data” doesn’t make a lot of sense as far as I can say.
yes it’s mainly about sload in storage.
for example, mapping(uint=>uint) m; /* m is empty */, when we call m[1], the storage in MPT do not contain any data about the slot, so maybe throw a exception is a choice.
It contains 0 by default.
Indicating “no data” would probably require a much more complicated scheme than the one currently implemented.