On 10 July 2013 12:47, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-07-10, at 13:32, Tudor Girba <tudor@tudorgirba.com> 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