code contracts - Should methods have the same preconditions as the methods they call? -

i've had few scenarios small changes code have resulted in changing preconditions across multiple classes , wondering if design contract supposed way or not.

public goal getnextgoal() {     return goalstack.pop(); } 

if goalstack.pop() has precondition stack isn't empty, getnextgoal() need explicitly have same precondition? seems inheriting preconditions make things brittle, , changing queue or other structure change preconditions getnextgoal(), it's callers, , it's callers' callers. seems not inheriting preconditions hide contracts , callers, , callers' callers, wouldn't know preconditions.

so brittle code callers know , inherit preconditions , postconditions of code call, or mysterious code callers never know deeper preconditions , postconditions are?

it depends on calling method exactly. the important thing preconditions caller responsible fulfilling preconditions.

so if callers of getnextgoal method should responsible providing non-empty stack, should indeed set preconditions on getnextgoal method. clarity of preconditions 1 of huge advantages of code contracts, i'd suggest put them in places callers have fulfill preconditions.

---

if code seems brittle however, it might sign need refactor code.

it seems inheriting preconditions make things brittle, , changing queue or other structure change preconditions getnextgoal(), it's callers, , it's callers' callers.

if expose queue callers , change later ( structure, said ), it's callers have change. sign of brittle code.

if expose interface instead of specific queue implementation, preconditions use interface , wouldn't have change preconditions every time implementation changes. resulting in less brittle code.