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. Esteban On Jul 9, 2013, at 5:42 PM, Clément Bera <[email protected]> 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 <[email protected]> > On 9 July 2013 16:24, Camillo Bruni <[email protected]> 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 > >
