I had a “swearing at Microsoft” moment at work. I was using the .NET XmlSerializer class.
The XmlSerializer class throws an exception when you instantiate the class! Even if there are no bugs in your code! The constructor throws and catches and exception!
Why does this matter? I had my code set to “break on all exceptions”, causing a breakpoint to be hit at that exception.
What kind of idiot designs a class that throws an exception AS PART OF NORMAL BEHAVIOR? Shouldn’t someone in QA somewhere catch this?
I haven’t looked up the documentation for this class, but I will have a guess.
Maybe you are not supposed to instantiate this class.
Maybe it only exists so that you can instantiate subclasses of it.
Maybe only the Microsoft library is suppose to instantiate this class. Maybe it is for internal use only. I suspect that only subclasses of it are suppose to exist as objects though. But then again they should have marked it as virtual, rather than throwing an exception.
Having said that Microsoft do hire a lot of at best average software developers. Then like hires like.
I was using the class as intended. My code was nearly 100% copied from an MSDN website example. It was listed as a “known bug” somewhere else.
OK, Microsoft sucks in this regard.
However once software gets above a certain size, it is very difficult to cope with the complexity.
My life went in a whole other direction, because I used a class written by someone else that failed at the first step of instantiation.
I was doing one project at a famous tech company and unfortunately the other software developer was a rubbish one and dishonest as well.
He produced a load of crap and many weeks late as well. His class failed at the first step of instantiation.
I thought as this guy was new to the company (and may be overworked) that I would give him the benefit of the doubt. I did tell the managers on the project that his software wasn’t ready on time though, but left it at that. I thought he might be incompetent but wasn’t sure.
Unfortunately this guy stuck the knife in my back. I did explain things to the managers, but they couldn’t be bothered to listen. His story gave them credit as well for saving the day, even though he was the problem.
So my life turned in another direction because of a class so badly written it failed at the first step of instantiation. It wasn’t just this, it was the fact that he produced bad code many, many weeks late.
It does seem peculiar that this code throws out an error as a matter of course. Did you resolve the issue in the end?
There was no solution.
When compiling for production, the code does not halt at the exception.
When debugging, I just ignore the exception and keep going.
Unfortunately I don’t think the competition is any better.
I think Microsoft has done a lot of good work with the .net framework. It is by far the best framework I have worked with. But there are rotten bits, and the xml serialization is for me one of the worst.
Not just that it’s buggy. I landed here because I needed to vent after XmlSerializer.Serialize completed without exceptions – but wrote INVALID XML! But really, xml serialization in .net is flawed from the design up.
If you use the standard serialization, all types involved must be public. They must all have parameterless constructors. If you have any abstract types you must statically describe which subclasses can occur (with XmlInclude attributes). So there went encapsulation and polymorphy out the window – but hey, it’s only the 2 most important reasons why OOP is powerful!
What is good about it is that it’s actually pretty fast. As far as I’ve understood the XmlSerializer is a facade and an implementation is generated (by Reflection.Emit) for the type you are working with. Then this is cached, so the next time your app creates a serializer for the same type it just instantiates the cached implementation and uses that behind the facade. Of course doing it this way is precisely why it can only ever work on public members.
The other serious limitation that makes .net xml serialization a no-go for me (when I get to decide) is that it cannot handle graphs correctly. Closed loops (a.other = b; b.other = a;) aren’t even detected, it just hangs forever. And other graphs will serialize/deserialize, but be altered in the process (a.other = c; b.other = c; => a.other = c1; b.other = c2; i.e. two instances of c rather than an a and a b pointing to the same c).
There isn’t even a good excuse for the latter shortcoming of the framework. Even I, who do not make a living making libraries that millions of others depend on, can keep track of a set of objects and figure out a way to represent a *reference* in XML. It’s not even particularly difficult. Then they could of course use an attribute if they absolutely want to let people “inline” shared objects, even though that would lead to the deserialized graph being different from the one serialized. But BY DEFUALT it seems quite obvious that the deserialized graph ought to be the same as the one serialized, and Microsoft doesn’t go out of it’s way to warn developers about these serious limitations.
I made my own xml serializer once and did manage to handle loops and arbitrary graphs. Mine was based on private reflection and only serialized *fields*, since fields are the true state of an object. (A property is a pair of methods and if it isn’t backed by a field, then it simply isn’t part of the object state.) The type in question did have to have a default constructor, but this could at least be private so the bad consequences of this (not being able to ensure correct state of the object by testing ONLY that type) were controllable. Since it used reflection it was comparatively slow, but in every other aspect I think it was heaps better than what we get in the framework. If I could do that in under one week, why isn’t the stuff we get better than it is?!?
You’re always going to get the best results writing your own serialize/deserialize function.
In my case, I was using a DataTable with 100% text data. The library constructor was throwing an exception internally, which is lousy library design and shows that someone at Microsoft didn’t QA properly.