On 9 July 2013 17:42, Esteban Lorenzano <esteba...@gmail.com> wrote: > Even more important, IMHO: allowing those methods to exists is to validate > an anti-pattern: if you have an specific error to throw, you should create a > specific descendant of Error, not just throw Error with an explanation. > > So, +A LOT to remove them.
No. Failing to specify your error messages is a colossal fail. And if you don't _test_ your error messages, how are you going to know you haven't just made your error messages utterly useless in that last refactoring? And no, checking that your KeyNotFound exception's #key is correctly set is insufficient, because you then _presume_ that the process of reporting the exception actually bothers to record that and doesn't just say "a KeyNotFound". By all means use a proper exception that captures semantic meaning. But, please, PLEASE actually test your logging. frank > Esteban > > On Jul 9, 2013, at 5:42 PM, Clément Bera <bera.clem...@gmail.com> wrote: > > They may be useful. Imagine you are too lazy to create a subclass of Error, > but not lazy enough to create a test and copy paste a String. > Then you write in your method: > self error: 'some strange error happened' > And you can test it: > self shouldnt: [ "some strange code" ] raise: Error > whoseDescriptionIncludes: 'some strange error happened' description: 'the > strange error did not happen ! That's strange' > > Seriously, as you saw these methods are used only in their tests. I guess > you can remove them. Open fogz bug ? > > > 2013/7/9 Frank Shearar <frank.shea...@gmail.com> >> >> On 9 July 2013 16:24, Camillo Bruni <camillobr...@gmail.com> wrote: >> > Survey: who uses the following methods? and if yes why? >> > >> > - shouldnt: aBlock raise: anExceptionalEvent >> > whoseDescriptionDoesNotInclude: subString description: aString >> > - shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionIncludes: >> > subString description: aString >> > >> > I honestly cannot wrap my head around these two methods. >> >> They show that the code in the block raises an _informative_ >> exception. So you get a FileNotFound exception... but what was the >> missing file? I don't know! Noone bothered to mention it! >> >> frank >> > >
