On 2013-07-10, at 14:47, Tudor Girba <tu...@tudorgirba.com> wrote: > Hi, > > On Jul 10, 2013, at 1:47 PM, Camillo Bruni <camillobr...@gmail.com> wrote: > >> On 2013-07-10, at 13:32, Tudor Girba <tu...@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? > > In the sense that they express two distinct classes of problems. > >> As a programmer I have to tackle them both the same way: start debugging. > > Yes, but not all debugging is created equal :) > >> I really do not see the difference. In both cases the code does not behave >> as expected. >> One might even say that there is a global contract that the code does not >> raise exceptions. > > Yes, but then what is the point of explicit assertions? :) > >> Tackling the failures first is purely a habit induced by the existing system >> that errors are worse than failures > > Actually, it is the other way around :). Errors are much faster to fix than > failures. Errors are often caused by bad initializations and you can see it > rather fast when you see the exceptions. On the other hand, failures are > often more sensitive to the deep semantics of your code and that is why they > require more time to get fixed.
That is fun, because everybody first takes the yellow ones because they come on top... So in the end the results should just be grouped by type of error I think.
