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
