throwing exceptions should not be done ad-hoc

what would you expect from this code?

System.Drawing.Image.FromFile("file.mp3")

Notice that i deliberately pass a non-image file to this function. Do you expect you will get InvalidImageFormatException? I would expect that, but as Microsoft documentation says it will return OutOfMemoryException.

Since when out of memory has something to do with image format? That's a rhetoric question of course, since .Net2 is many years on the production already :)

Reading XmlNode.AppendChild Method documentation

While reading XmlNode.AppendChild documentation i found myself thinking of this:

If I have the following code, what would be its result?

XmlNode parentNode = new XmlNode(...);
XmlNode childNode = new XmlNode(...);

parentNode.AppendChild(childNode);
parentNode.AppendChild(childNode);

Console.WriteLine(parentNode.Childs.Count)

By reading the code i would tell that we would get two children. But by reading the documentation you can find that it will be one. Take a careful look at the following sentence in official Microsoft documentation.

If the newChild is already in the tree, it is removed from its original position and added to its target position.

How the in the world I can understand from the method name "AppendChild" that it not only appends, but removes and then appends?

So yes, naming your functions correctly is very important for clean code.

Asynchroniaus data fetching with NHibernate

yes, that, AFAIK, does not work out of the box. Up to know the following thoughts come to my mind:

How does ISessionFactoryHolder react to multiple threads? Does it generate one session factory holder or one for each thread?

Looking at ThreadScopeInfo.cs:26 we see this code

[ThreadStatic] static Stack stack;

This clearly tells that we have a new stack of of session scopes for each thread.

Googling around i've came to this post. It suggested to just register your own thread-safe implementation of IThreadScopeInfo.

While I think that is OK and might solve the problem, but why reinvent, whenc Castle.ActiveRecord already provides the following implementations of IThreadScopeInfo:

• AbstractThreadScopeInfo - this is used as an abstract implementation, not useful


• HybridWebThreadScopeInfo - the docs say: This is used for scenarios where most of the you need per request scope, but you also does some work outside a request (in a thread pool thread, for instnace).


• ThreadScopeAccessor - This is just an accessor, and does not provide single scope for all threads


• ThreadScopeInfo - this is the default implementation, which has static instances per-thread


• WebThreadScopeInfo - this implements a Session Per Request pattern pattern, So not useful

So, no helpful implementation, so will do the same as suggested here. But, really, i hate copy-paste things, that's pure evil