tag:blogger.com,1999:blog-8416807644832025349.post5376697833845225314..comments2016-03-03T11:26:59.889-08:00Comments on Lexical Closures: Cryptic Rhino Mock exception messagesUnknownnoreply@blogger.comBlogger6125tag:blogger.com,1999:blog-8416807644832025349.post-4621384922118249152008-12-13T15:33:00.000-08:002008-12-13T15:33:00.000-08:00AndrewI have not been fortunate enough to work on ...Andrew<BR/><BR/>I have not been fortunate enough to work on a project using the latest in Rhino Mocks coupled with C# 3.x but I definitely would like to experience for myself some of the syntactical improvements you mention.<BR/><BR/>I do plan on taking a look at Moq (http://code.google.com/p/moq/) to see how it holds up in those same areas.Ray Vegahttps://www.blogger.com/profile/08881925233876970678noreply@blogger.comtag:blogger.com,1999:blog-8416807644832025349.post-17340269754382165542008-12-11T15:24:00.000-08:002008-12-11T15:24:00.000-08:00Ray, as you say the article is quite old but nothi...Ray, as you say the article is quite old but nothing seem to have changed in error messages by now :)<BR/><BR/>Just starting to fumble with RhinoMock - C#3 support in the latest version really makes a difference.<BR/><BR/>BTW, Expects still don't work with void methods - but lambda expressions make this problem less painful even in "old-fashioned" way of setting expectations:<BR/><BR/>Expect.Call(() => hand.TouchHotIron(iron)).Throw(new BurnException());<BR/><BR/><BR/><BR/>(just a note to someone who may have googled the article)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8416807644832025349.post-90720325824850069972008-09-26T00:51:00.000-07:002008-09-26T00:51:00.000-07:00@snealAdmittedly, I wrote this over a *year* ago s...@sneal<BR/><BR/>Admittedly, I wrote this over a *year* ago so it was based on whatever version Rhino Mocks was at the time. <BR/><BR/>Haven't had an opportunity lately to see if it's improved but good to know.Ray Vegahttps://www.blogger.com/profile/08881925233876970678noreply@blogger.comtag:blogger.com,1999:blog-8416807644832025349.post-19243397661333008382008-09-24T11:39:00.000-07:002008-09-24T11:39:00.000-07:00Overall I prefer the Rhino error messages since th...Overall I prefer the Rhino error messages since they are short and concise, however I do agree:<BR/><BR/>1. Property errors should show the C# name, not the underlying .NET name. set_MyProp is a little annoying.<BR/>2. I like the consistency of Expect in NMock2, this is especially true for noobs.<BR/><BR/>I'm pretty sure your last example (string with DateTime) won't compile in RhinoMocks 3.4 since it uses generics. At one point it didn't.<BR/><BR/>RhinoMocks 3.5 syntax is much cleaner and more consistent IMO. So drop everything else and use that.Anonymoushttps://www.blogger.com/profile/12673546248813988214noreply@blogger.comtag:blogger.com,1999:blog-8416807644832025349.post-49815650422119052332008-09-10T10:36:00.000-07:002008-09-10T10:36:00.000-07:00@urs enzlerI found if you use ReSharper then the s...@urs enzler<BR/><BR/>I found if you use ReSharper then the strings as used in NMock2 can just as easily be renamed as if they were strongly typed.<BR/><BR/>The only catch is Re# is not free. Not an issue for me since I have a license but can be for others.Ray Vegahttps://www.blogger.com/profile/08881925233876970678noreply@blogger.comtag:blogger.com,1999:blog-8416807644832025349.post-70580943331489759812008-09-10T09:21:00.000-07:002008-09-10T09:21:00.000-07:00I agree, Rhino Mock and MoQ as well, are strongly ...I agree, Rhino Mock and MoQ as well, are strongly typed. But we invest a lot to provide good exception messages and a clear syntax with NMock2. That's the reason we stick with NMock2: clear and easy syntax, good exception behavior and good extensibility.<BR/><BR/>Happy mocking (which ever mocking framework you use :-)Anonymousnoreply@blogger.com