On 5 Mar, 06:43, "Kirit S=E6lensminde" <kirit.saelensmi...@gmail.com>
wrote:
On Mar 4, 6:36 pm, "GavinDeane" <deane_ga...@hotmail.com> wrote:
On 4 Mar, 10:29, rpbg...@yahoo.com (Roland Pibinger) wrote:
Is a contract violation a bug or an expected runtime scenario? IMO,
the latter.
How do you engineer a reliable product if you expect third party
components (software or hardware) not to adhere to their interface
specifications? If you expect them to do that you need to change
supplier.
Isn't the ability to do just that what we strive to do? To write
reliable software even in the face of the unexpected?
There may be a confusion over the meaning of "expected" here. I was
responding to Roland Pibinger's phrase "expected runtime scenario"
believing he meant that a contract violation by a third party
component was a normal ("expected") event and that your program is
inherently flawed if correct behaviour relies on third party
components not violating their contracts.
By definition, the only way [*] it is possible for a component to
violate its interface specification is if it has a bug. And you can't
build a reliable product if one of the components has a bug. If the
bug is in a component you produce, you need to fix the bug. If the bug
is in a third party component, you need to change supplier (or get the
current supplier to fix their product).
[*] Assuming the documentation fully describes the interface. But
then, if it doesn't, you don't have the information needed to
integrate that component into your product in the first place.
OK. I think I see where you're coming from. It seems you're talking
availability of any debugger. I do use exceptions for the purposes