We completed the SouceGear project!
The project included adding a lot of functionality to Mono to support Web Services on the client (mostly having a full XmlSerializer implementation as well as its close family members) and making Mono robust.
To make sure that Mono was robust, SourceGear designed a series of extensive tests that Mono would be put under, and the acceptance criteria for the work we did included running the tests for a 24 hour period of time on a single instance of the virtual machine. Needless to say, making the Mono VM robust enough to run these tests for 24 hours was not easy, and we ran into all sorts of low-level interesting features, memory leaks, race conditions and other assorted small problems that would not have shown under normal circumstances. We are very happy about this.
In the meantime, while parts of the team were tracking down the elusive bugs in the runtime, Lluis took the time to implement the server side component of ASP.NET, so as part of the SourceGear effort, we also got our web services stack implement on the server, which was a nice plus.
I was feeling that I should argue a bit more about exceptions, until I received a mail from Krzysztof Cwalina at Microsoft, he raises a good point about exceptions and the null return pattern: they do not allow an error to be propagated, nor details about the error.
He is absolutely right, and my example with files was not a good one. I had in mind APIs that did not need to propagate a rich error or details about the condition. Krzysztof said:
One problem with null is that you may get notified about the problem really far away from the point when the error occurred. Exception will be thrown right there at the point where the error occurs. The other problem is that null cannot tell you why the error occurred. Error codes have their own set of problems.
Of course (as with every design) it's a tradeoff. In this case a tradeoff between better error reporting (fail fast, rich error message) and performance (and other things). In general, we err on the side of better reliability, clarity of errors, etc. when designing the Framework. We have several exceptions to the general rule in explicitly identified performance-sensitive APIs.
Lluis the man behind the Mono implementation of Remoting and Xml Serializer explains on his latest blog entry how the undocumented IXmlSerializable interface works. If you ever wondered how you could have precise control over the Xml mapping in XmlSerializer, this is the interface used internally by the framework.
Sebastien, the man behind the Mono cryptographic infrastructure now has his own blog.
Duncan also started his
Posted on 01 Oct 2003