Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,317 | Comments: 46,912

filter by tags archive

Debugging the problem that never was

time to read 2 min | 248 words

I just spend ~3 hours trying to find out why my error reporting system doesn't work. The situation was simple, I wanted to have a tree view that display the structure of an XML document, and show an error icon if there are any schema errors. The idea was that the error would propogate up, so an error in any child would show in the parent, and the grandparent, etc.

But I couldn't get that to work. I debugged it endlessly, I made a lot of changes (some of them were even neccesary :-) ) in order to find out what the problem was. In the end, I verified that it work if I'm changing the text of the TreeNode it does propogate up. But it didn't work if I was using the icons.

Then I did something very simple, I moved the selection from the root to the second node, and the icon has changed! Apperantly the problem was that if you define an ImageList for a tree, you get 1+1, a selected image. That was my problem, both the selected image and the okay image were the same, and that was what was causing the whole problem.

It get weirder, you can't disable the SelectedImageIndex, and I'm not sure if this is the framework fault or VS.Net. I ended up with a SetImageIndex() method that set for both of them at once. Yuck!


time to read 3 min | 463 words

[Update: I create a ladybug suggestion for this, go vote for it]

I made some checking after this, by I seems that there isn't any way to tell whatever an exception occured when you're in a finally block. This is stupid, there are plenty of use cases where this is needed. Consider transactions, for instance:

using(Transaction transaction = session.EnterTransaction())
  // Do work with the transaction

Because when you're in the Transaction.Dispose() there is not way to know if an exception was thrown or not, you must call the transaction.Commit() so it would know what to do. This is very easy to forget and can cause problems because the code look correct.

I suggest a new interface:

public interace ISmartDisposable : IDisposable
  void Dipose(Exception exception);

And the previous using statement (without the transaction.Commit() ) would expand into something like this:

Transaction transaction = session.EnterTransaction();
ISmartDispose sd = transaction as ISmartDispose;
Exception exception = null;
  // do work
catch(Exception ex)
  exception = ex;
 if (sd != null)//this line is s bug, removed

Now the transaction knows whatever an exception occured or not and can commit/rollback properly.  In the case of an object that implements IDisposable, the using statement should just fall back to the current behavior.

This is not just limited to transactions, and disposable object that need to know if an exception was raise can benefit from this. Rhino Mocks' MockRepsitory currently raise exceptions when the problem is locate elsewhere if an exception was raised by something other than the framework.

Considerring that this is merely a compiler constrcut, I'm thinking about implementing it in Boo.

Rhino Mocks 2.0.7

time to read 1 min | 90 words

Rhino Mocks 2.0.7 is mainly a bug fix for method orderring bug, but it also present a better package in that that you no longer has to have Castle.DynamicProxy.dll with the Rhino.Mocks.dll

No, I didn't implemented my own IL generator, I simply used ILMerge and the results are very satisfying. I'm thinking about doing the same for Brail (which comes with several dlls) but this cause tests to fail, and I didn't have the time to find out what the problem was.

A simple way to avoid repeated questions in forums

time to read 1 min | 74 words

Check out this post by Lee, it show a very simple way that can reduce the amount of repeated questions in forums / bug tracking / support systems.

This should be very simple to implement and over time should truly reduce the amount of novice questions. Like all good ideas, it's actually a very simple one (with corresponding simple implementation).

Check the screenshot.

The next version of Brail

time to read 1 min | 101 words

I've purposed a couple of changes to the Boo's parser, which - if accepted - would make for a much better experiance in using Brail. But if not, I've been reminded that I can just fork the parser alone, and create a Brail parser which could do more crazy things to the langauge to make it easier to work on the web.

Currently I want to enable the use of raw string (and string interpolation) in the scripts, and perhaps also enable the <% %> syntax that should be familiar to everyone by now.

Proposal: Implementing contracts in Boo

time to read 12 min | 2298 words

(This is a suggestion I'm making for the Boo's mailing list, about a proposed syntax for Eiffel's like contracts for Boo)

[This proposal require inherited Ast attributes, which provides some challanges in the implementation. More on this in a moment.]

The idea is to allow to use attribute markup to create pre & post conditions for a method. Here are the sematics or this proposal:

  • Pre conditions apply to the current method and all the method that override it:
    • Considerring that difficulities in checking in compile time that a class accept equal to or wider range of parameters (rather than a narrow range) I don't think that this practical.
    • It's not hard to implement this check in run time where you can ensure that if the base method pre condition has passed then the method must accept it or violate its contract. So this what this proposal does. An exception (with very silly name) is raise if a parent's base condition is satisfied but the child condition has failed.
  • Post conditions apply to the current method and all the methods that override it:
    • Again, statically checking the correctness of the post condition is prohibitive, and much simpler to do on run time.
    • Post conditions are stacked, and a post condition that allows something that the base method wouldn't allow will cause a contract exception

Without further ado, here is the proposed code and the final translation (see more comments about the implementation below):

public class ClassWithContract:     
#post & pre are Inherited AstAttributes
virtual def FirstMethod([pre(foo.Property == "object")]foo as someType) as anotherType:
return DoWork(arg)
public class DerivedClassWithNoOverridingContract(ClassWithContract):     
override def FirstMethod(foo as someType) as anotherType:
return DoDerivedWork()
public class DerivedClassOverrideContract(ClassWithContract):     
override def FirstMethod([pre(foo.Property is not null)] foo as someType) as anotherType:
return DoDerivedWork2()

The above would be translated into the following:

public class ClassWithContract:     
protected virtual def post_FirstMethod(result as anotherType) as bool:
return PerformComplexVeriication(result)
    # the syntax for this is pre_<method name>_<arguments>_<arguments this method check>     
# this is done in order to handle overloading
protected virtual def pre_FirstMethod_someType_arg(foo as someType) as bool:
return foo == "object"
    # this attribute is check by the ocmpiler and if found it will invoke the specified     
# attribute on any overloading method and then apply to it the same AST attribute
[InheritorUseAstAttribute("Boo.Lang.Useful.PostAttribute, Boo.Lang.Useful")]
[InheritorUseAstAttribute("Boo.Lang.Useful.PreAttribute, Boo.Lang.Useful")]
virtual def FirstMethod(arg as someType) as anotherType:
raise PreConditionFailedException("arg") if not pre_FirstMethod_someType_arg(arg)
__result = DoWork(arg) raise PostConditionFailedException() if not post_FirstMethod(__result)
return __result
public class DerivedClassWithNoOverridingContract(ClassWithContract): 
    # pre condition of base method is enforced     
# post condition is enforced
# this doesn't have any special pre/post condtions of its own
override def FirstMethod(foo as someType) as anotherType:
raise PreConditionFailedException("arg") if not pre_FirstMethod_someType_arg(arg)
__result = DoDerivedWork()
raise PostConditionFailedException() if not post_FirstMethod(__result)
return __result
public class DerivedClassOverrideContract(ClassWithContract): 
    # override the parent post condition and then call it:     
protected override def post_FirstMethod(result as anotherType) as bool:
currentCondition = PerformComplexVeriication(result)
baseCondition = super(result)
raise ContractViolationChildDontAcceptSuperDoesException() if currntCondition
and not baseCondition

return currentCondition
 protected override def pre_FirstMethod_someType_arg(foo as someType) as bool:     
baseCondition = super(foo)
currentCondition = foo .Property is not null
# need to work on the name of this exception :-)
raise ContractViolationChildDontAcceptSuperDoesException() if baseCondition and not currentCondition
return currentCondition
    [InheritorUseAstAttribute("Boo.Lang.Useful.PostAttribute, Boo.Lang.Useful")]     
[InheritorUseAstAttribute("Boo.Lang.Useful.PreAttribute, Boo.Lang.Useful")]
override def FirstMethod(foo as someType) as anotherType:
raise PreConditionFailedException("arg") if not pre_FirstMethod_someType_arg(arg)
__result = DoDerivedWork2()
raise PostConditionFailedException() if not post_FirstMethod(__result)
return __result

A few comments about the proposal:

  • Adding a class invariant would be a very simple matter if we take this approach
  • Setting a contract for an interface may be problematic, since there is no place to put the methods, in this case I propose that a utility class will be created and used by all the classes that implement the interface.
  • What happen when a post/pre condition raise an exception?
  • I don't like the idea of easing the limitation, or of not implementing the contract exception. The reasoning is very simple, right now a post / pre condition need to takes into account each and every parent's condition. I suggest that we would simply stack them together, and if any fail the Pre/Post condition exception would be raised, without checking for the correctness of the contract.
  • How do you debug this?
  • How do you get the contract from a compiled dll so you would know what it is? Do we rely on documentation or should we live something in the IL to be read later?

What is needed to implement this?

Not much, actually :-) which is very good. I played with my mind a little with this and this is what is needed to create this proposal:

  • An abstract attribute (AbstractInheritedAstAttribute) that inherit from AbstractAstAttribute that will handle inheritance to overriding methods (or derived class, if we wants class invariants as well). This attribute will "tag" any method/class that it is used upon with a normal attribute (in the sample InheritorUseAstAttributeAttribute which will have the full type name of the Ast attribute.
  • Adding a compiler step that will process any method/class that has this attribute in their parentage chain and call the Ast attribute on the current memeber.

[This is a rough draft that was mainly formulate during IRC discussion early this morning.]

Exception Information From Finally?

time to read 2 min | 246 words

I've a problem in a Dispose() routine, the problem is that I need to know if I got to the Dispose() as a part of normal execution or if I got there because of an exception in a using() block.

I know that it has been tried before for transactions, but I don't know if there has been any success there. Here is what I'm trying to achieve:

IDisposable dispoable = new MocksRepository();
  throw new Exception();
  if (/*an exception occured*/)

Sick with #Develop

time to read 3 min | 480 words

[Update 31/07/2005 19:08: Fixed the name of the boo bindings for #Develop' author, sorry for the mixup.]

I'm getting sick of SharpDevelop, it can't handle even basic IDE stuff correctly. I'm not talking about rocket science here, I'm talking about basic functionality like moving files from one folder to the other, adding a folder and renaming it, drag & drop of project files to open the project and not the file's text etc.

The single saving grace for #Develop is that it has boo integration, which mean that I can get IntelliSense that mostly work. But when I need to quit the IDE and modify by hand the project file every time I want to add a directory... that is more than enough. I tested #Develop several times in the past. My final conclusion is that about the only mature part of this software is the text editor (and even that is missing basic functionality like word wrapping [notepad has it, for crying out loud]). It has gotten to the point where I currently can't compile Brail using SharpDevelop while it compiles cleanly using NAnt (and no, I didn't had things in NAnt that I didn't have in #Develop)!

I was chatting with a friend and he sent me this screen shot from XDevelop, check out their site, the demo in their site looks very good:

Do you the little green vees? Those are passing tests, and there are plenty more functionality where this came from (refactoring, code browsing, etc).

This is not freeware, and it doesn't support Boo, so I'm going to pass on it for now (although not forever!) and see what JetBrains has to offer with their .Net 2.0 IDE.  Daniel Grunwald wrote the boo integration for #Develop. Arron has started a similar project for VS.Net (which is now on hold because of the VS Extensibility team stupidity) and he has plans to write an integration package for Boo. I already talked with JetBrains and they stated that not only will the IDE be open for extensibility, but you would get all the goodies regardless of the langauge. This is something that I would have too see to believe, but it's certainly better than what #Develop offers.

Currently I'm digging into jEdit with Boo syntax coloring and some nice plugins, here is my current work:

Notice that the syntax for Boo is nearly identical for the one used by VS.Net for C#. Do you see at the bottom the bulid script? Propertly syntaxed? It's not an IDE, but it's close enough, and it's certainly more stable than #Develop

Rhino Mocks 2.0.6

time to read 3 min | 493 words

Okay, this release is actually an interesting one. The problem it solves is running Rhino Mocks on the .Net 2.0 Framework.

Somewhere deep in the bowels of Rhino Mocks, there is a method that return a default value for method that are called during the recording phase, it looks like this:


static object DefaultValue(Type type)
if (type.IsValueType == false)
return null;
return Activator.CreateInstance(type);

The problem was what would happen when you get a void type [ typeof(void) ]. On .Net 1.0 and 1.1 this just worked, and you actually got a System.Void instance that you could play with. On .Net 2.0, you get a not supported exception, which seems reasonable, except that it breaks my code and that is not reasonable :-)

Anyway, on a hunch, I modify the code to do this:

public static object DefaultValue(Type type)
  if (type.IsValueType == false || type==typeof(void))
    return null;
  return Activator.CreateInstance(type);

And now it's working. And no, methods with void return type won't start to return nulls all over the place. Dyamic Proxy handles it, acutally. It simply discard any return value from the interceptor for a method with a void return value, so everything is happy again.

I'm currently installing .Net 2.0 and I'll give Rhino Mocks a twirl using C# 2.0, and see if all the tests pass on it. What do you think should change to accomodate 2.0 beyond the obvious:

IAnimal pet = mocks.CreateMock<IAnimal>();


  1. RavenDB Conference videos: Zapping ever faster: how Zap sped up by two orders of magnitude using RavenDB - 16 hours from now
  2. Feature intersection bugs are the hardest to predict - about one day from now
  3. RavenDB Conference videos: Implementing CQRS and Event Sourcing with RavenDB - 3 days from now
  4. How did the milk get to the fridge? - 4 days from now
  5. RavenDB Conference videos: Building Codealike: a journey into the developers analytics world - 7 days from now

And 9 more posts are pending...

There are posts all the way to Mar 10, 2017


  1. RavenDB Conference videos (12):
    17 Feb 2017 - Should I use a document database?
  2. Low level Voron optimizations (5):
    20 Feb 2017 - Recyclers do it over and over again.
  3. Implementing low level trie (4):
    26 Jan 2017 - Digging into the C++ impl
  4. Answer (9):
    20 Jan 2017 - What does this code do?
  5. Challenge (48):
    19 Jan 2017 - What does this code do?
View all series



Main feed Feed Stats
Comments feed   Comments Feed Stats