This happens because of the fact, that Xtend generates mandatory try/catch block for each lambda expression. Lambdas are particularly useful to match arguments or to return custom results:
service.generateEMail(any, any, any)
result = [ String to, String subject, String body |
''' To: «to» Subject: «subject» «body»'''.toString
Analyzing the code of JMockit I found no way to disable "try/catch statement" checking.
Could you please add a "disable try/catch statement" option to the next release?
Please keep in mind, that I don't have any control over "-D" java parameters.
A global static boolean field or local switch disabling the check just for the upcoming expectations-block will both do the trick.
Here are some additional snippets for you:
expectationsAPI.paramsString(with [ (it?:"").length >3 ])
I think there's a better solution, which is to allow conditions/try..catchs inside methods, while still disallowing them inside constructors of the Expectations/Verifications subclass. I can make this change for the next release.
Hi, I just started to use JMockIt in my unit testing and I feel this mock framework is really awesome. I also meet this questions when writing code for Verfications. I am just curious about why conditional checking is enabled in such blocks? Because from my point of view, it quite makes sense to support try/catch in such blocks. I suspect that I am not doing as the best practice if it is not supported.
I am doing some verifications to check whether returned protobuf data is correct or not. So I mocked the Channel object in Netty and captured the returned protobuf data. However the Protobuf will throws some exceptions and I have to use the try catch to avoid errors.