Maybe we should not throw away the distinction, I am used to it as well. But what Camillo means, I think, is that in the end it does not matter.
For example, if I have a unit test for some object's #printString both the case where is does no longer return what I expect and the case that it suddenly throws an error mean the same thing: the object's #printString is broken. Sven On 10 Jul 2013, at 13:55, Frank Shearar <[email protected]> wrote: > On 10 July 2013 12:47, Camillo Bruni <[email protected]> wrote: >> On 2013-07-10, at 13:32, Tudor Girba <[email protected]> wrote: >>> Precisely. There is a huge difference between invalidating a known contract >>> (i.e., failure) and raising an unexpected error (i.e., error). >> >> In which sense? >> As a programmer I have to tackle them both the same way: start debugging. >> >> I really do not see the difference. In both cases the code does not behave >> as expected. > > Yes, you do need to approach the problem in the same way - open the > debugger - but I don't think that's sufficient reason to lose the > distinction. Implementing a new feature also involves opening a > debugger, but we keep the distinction between "writing new code" and > "debugging existing code". > >> One might even say that there is a global contract that the code does not >> raise exceptions. > > That last part's not true. I don't know what "global" means, but lots > of code will explicitly have as its contract "halt and catch fire". > >> Tackling the failures first is purely a habit induced by the existing system >> that errors are worse than failures > > Maybe, but it's still a useful distinction. "Oh, this feature broke" > isn't the same as "hang on, that's a brand new bug". > > frank >
