3 ms·
If this combines with transactional semantics, which is table stakes for a language like this, then yes, any exceptional state which isn't accounted for should
by samatman 4y ago
If this combines with transactional semantics, which is table stakes for a language like this, then yes, any exceptional state which isn't accounted for should be equivalent to nothing whatsoever happening over the entire state change the contract was enacting.
If only Solidity worked that way. But I guess databases weren't an important thing to study.
- jerf 4y agoIt was more the complete inability to catch aborts that caught my eye. Aborting strikes me as a good enough default, but I might like to be able to recover from something bad happening. In the particular case of math you can still write a plus that detects whether it would overflow first, but in general catching aborts seems like a good bit of functionality. Personally, if I were writing a serious language like this I'd consider turning all + operations into things that return two results, one for the result and one for if it succeeded. Do it Go-style, do it with a Result type, I don't much care. The point is just that in the context of something like this, bringing it to the programmer's attention that + is not a safe operation on every usage is probably worth it. I reluctantly concede it is overkill in normal languages, but if there is ever a time to bite that bullet and make them do a full Result-style unpacking on every arithmetic operation, it's here.