I'm trying to get NHibernate to load some records for me (it's been partially set up, and is used for some other parts of the app already), and while working on an <any> mapping, I got this exception:
[InvalidOperationException: any types do not have a unique referenced persister]
Can somebody help me parse what they mean by this? I can think of many completely different meanings for this sentence. I can interpret the first part as:
types declared with <any> are not allowed to have a URP, but yours do
types declared with <any> must have a URP, but yours don't
any of your program's types should ...
And with any of these, I can see the second part as:
you have more than one persister, but only one is allowed
you have no persister, but one is required
you have one, but failed to reference it correctly
(Yeah, I'm unclear on much of their terminology still, but usually when I'm unclear on some parts, error messages are at least clear enough that I can figure out what they mean by context. And the exception points to the entry point into NHibernate, not a bad mapping in my .hbm.xml file or a property in a specific class.)
I've looked at the API docs, but they seem completely unhelpful here.
thanks!
I interpret that as your first bullet point does; I do not understand your question about the "second part".
Related
I'm getting the abovementioned error message, and I'm hoping that someone can translate the thing for me. The only references I've found online in a bit of searching are quotes from code blocks without explanation. They look like they're related, but they don't actually offer any help in figuring out what's going on.
background: I'm trying to maintain a chunk of legacy code in an mvc2/C#/EF/SQL stack, which uses these materializers (and, presumably, readers) as a way to communicate with the database. I have essentially no understanding of how materializers work beyond the "oh, that seems sort of like it does something like this" that you get just from a read-through of the code itself. I had to make some changes to the database on one of the table/object sets that used a materializer. I adjusted the materializer appropriately (as far as I can tell), cheating off of the existing code heavily to add equivalent lines for the columns/properties that were added, and removing lines for those that were removed. I also commented out a function in the c# class called TryParse, because as far as I could tell, nothing used it, and we're attempting to cut down on the cruft a bit. It now appears to fail some, but not all, of the time when the thing is used. I really do not know whether it was failing like this before my changes or not.
I don't need an answer of what exactly is going on - I have a suspicion that that would take way too much commenting of code blocks and whatnot. Mostly, I'm hoping that someone can give me a general pointer or two of the "ah, this error message generally means that" variety, so that I'm not flying completely blind (though if anyone is able to come up with more than that based on the information I've given, that would be great).
Thank you for your time.
The error message is from EFExtensions. The source indicates that this error is thrown when the shape (field count and field names) of a record in a reader doesn't match the shape the materializer expects.
(A materializer is just something that makes object instances out of something else, in this case data read by a reader)
It's not immediately clear to me from the EFExtensions source how this can happen in the 'normal' case, as it looks like the expected shape is inferred from the first record read, and then all subsequent records are checked against that. Obviously for a normal IDataReader, all the records will have the same shape.
However, it sounds like you might have custom materializers at work (possibly inheriting from the EFExtensions ones, hence why you're getting their error messages), in which case the answer might lie in your materializer code.
I've noticed that most exception messages don't include instance-specific details like the value that caused the exception. They generally only tell you the "category" of the error.
For example, when attempting to serialize an object with a 3rd. party library, I got a MissingMethodException with message:
"No parameterless constructor defined for this object."
In many cases this is enough, but often (typically during development) a message like
"No parameterless constructor defined for this object of type 'Foo'."
can save a lot of time by directing you straight to the cause of the error.
InvalidArgumentException is another example: it usually tells you the name of the argument but not its value.
This seems to be the case for most framework-raised exceptions, but also for 3rd party libraries.
Is this done on purpose?
Is there a security implication in exposing an internal state like the "faulty" value of a variable?
Two reasons I can think of:
Firstly, maybe the parameter that threw the exception was a value that was a processed form of the one that was passed to the public interface. The value may not make sense without the expense of catching to rethrow a different exception that is going to be the same in most regards anyway.
Secondly, and more importantly, is that there can indeed be a security risk, that can be very hard to second-guess (if I'm writing a general-purpose container, I don't know what contexts it will be used in). We don't want "Credit-Card: 5555444455554444" appearing in an error message if we can help it.
Ultimately, just what debug information is most useful will vary according to the error anyway. If the type, method and (when possible) file and line number isn't enough, it's time to write some debug code that traps just what you do want to know, rather than complaining that it isn't already trapped when next time you might want yet different information (field state of instances can be just as likely to be useful as parameters).
InvalidArgumentException and (per #Ian Nelson) "Key not found in dictionary" both share something in common - there's no guarantee that the framework would be able to find a suitable value to show you - if the key/argument is of any user defined type, and ToString() hasn't been overridden, then you would just get the type name - it's not going to add a lot of value.
Exceptions are mostly meant for a program to consume. Most programs wouldn't know what to do with information about the instance.
The Message property is aimed at human consumption. Other than in a debugging scenario, humans won't know what to make of Foo.
Many exception mechanisms try to serve a hodgepodge of orthogonal purposes by passing a single exception-derived object:
Letting the caller know that various specific things have happened, or that various specific problems exist.
Determining when the exceptional condition is "resolved" so that normal program flow can continue.
Providing an indication of what to tell the user of the program
Providing information which could be logged to allow the owners of a system to identify problems, when a secure log is available
Providing information which could be logged to allow the owners of a system to identify problems, but which would not pose a security risk even if secure logging is not available.
Unfortunately, I'm unaware of any exception mechanism in widespread use which can actually accomplish all five of the above, well.
I'm writing an XML code editor and I want to display syntax errors in the user interface. Because my code editor is strongly constrained to a particular problem domain and audience, I want to rewrite certain XMLException messages to be more meaningful for users. For instance, an exception message like this:
'"' is an unexpected token. The
expected token is '='. Line 30,
position 35
.. is very technical and not very informative to my audience. Instead, I'd like to rewrite it and other messages to something else. For completeness' sake that means I need to build up a dictionary of existing messages mapped to the new message I would like to display instead. To accomplish that I'm going to need a list of all possible messages XMLException can contain.
Is there such a list somewhere? Or can I find out the possible messages through inspection of objects in C#?
Edit: specifically, I am using XmlDocument.LoadXml to parse a string into an XmlDocument, and that method throws an XmlException when there are syntax errors. So specifically, my question is where I can find a list of messages applied to XmlException by XmlDocument.LoadXml. The discussion about there potentially being a limitless variation of actual strings in the Message property of XmlException is moot.
Edit 2: More specifically, I'm not looking for advice as to whether I should be attempting this; I'm just looking for any clues to a way to obtain the various messages. Ben's answer is a step in the right direction. Does anyone know of another way?
Technically there is no such thing, any class that throws an XmlException can set the message to any string. Really it depends on which classes you are using, and how they handle exceptions. It is perfectly possible you may be using a class that includes context specific information in the message, e.g. info about some xml node or attribute that is malformed. In that case the number of unqiue message strings could be infinite depending on the XML that was being processed. It is equally possible that a particular class does not work in this way and has a finite number of messages that occur under specific circumstances. Perhaps a better aproach would be to use try/catch blocks in specific parts of your code, where you understand the processing that is taking place and provide more generic error messages based on what is happening. E.g. in your example you could simply look at the line and character number and produce an error along the lines of "Error processing xml file LineX CharacterY" or even something as general as "error processing file".
Edit:
Further to your edit i think you will have trouble doing what you require. Essentially you are trying to change a text string to another text string based on certain keywords that may be in the string. This is likely to be messy and inconsistent. If you really want to do it i would advise using something like Redgate .net Reflector to reflect out the loadXML method and dig through the code to see how it handles different kinds of syntax errors in the XML and what kind of messages it generates based on what kind of errors it finds. This is likely to be time consuming and dificult. If you want to hide the technical errors but still provide useful info to the user then i would still recomend ignoring the error message and simply pointing the user to the location of the problem in the file.
Just my opinion, but ... spelunking the error messages and altering them before displaying them to the user seems like a really misguided idea.
First, The messages are different for each international language. Even if you could collect them for English, and you're willing to pay the cost, they'll be different for other languages.
Second, even if you are dealing with a single language, there's no way to be sure that an external package hasn't injected a novel XmlException into the scope of LoadXml.
Last, the list of messages is not stable. It may change from release to release.
A better idea is to just emit an appropriate message from your own app, and optionally display -- maybe upon demand -- the original error message contained in the XmlException.
I'm working on a T4 template to automatically generate a C# class definition from an XML file. For each element in the XML document I'd like to determine the type of the content in that element. Is there a framework class that handles automatically determining a type from a string value?
That is a very interesting question but I am afraid you are going to have a tough time finding anything in the FCL that will do this.
If you think about it, your problem is a rather unique one, you have a known type as a conversion source and an unknown output type. This doesn't come up too often in day-to-day coding using a framework like .NET.
Since the .NET framework is designed to be used with strongly-typed languages, types are very important and most of the time we know what type we want and can request a conversion from some generic source (like a string or an object) to that specific type. That is why we have casting, conversion methods (like Convert.ToInt32 and such), and similar things. They are all designed to allow us to directly state the output type of the conversion since we know what it is that we want to get.
All that being said, I would be interested to see if someone else has written something like this because the parsing that would be involved in getting this to work must be very similar to the C# compiler itself in the way that literal values are handled in source code.
You might want to take a look at the reflected source of XSD.exe and/or the some of the code in the System.Xml.Serialization.Advanced.SchemaImporterExtension class where you can control some of the advanced serialization stuff. In the past XSD has done a pretty good job of getting a starter schema file generated from a XML file.
In forward referencing language such as c#, how does the compiler handle this? What are the steps in which the compiler operate?
The main difference between allowing forward reference or not is using a one pass compiler or a multi pass one. Of course to handle forward referencing you have to check symbols definitions and do typechecking AFTER having generated the full abstract syntax tree of the source you are compiling.
So there is no problem, when you first find a forward reference you just rely that it will be defined later (you can mark it as pending in symbol table) then when you find the actual definition you refine the symbol object in symbol table.
After you can typecheck it or check if some symbols are still pending (so there is no real definition, and you can raise a semantic error)..
It does this by doing two passes of compilation. The first pass parses the code and collects all identifiers used. The second pass resolves all identifiers.
In a language with a single pass compiler, like Pascal, only backwards references can be used as the type of an identifier have to be known before it can be resolved.
exactly the same way C++ handles it, I think, only difference: the syntax is simple enough that the compiler can construct the parse tree without needing you to tell what kind of syntactical object your yet undeclared symbols refer to.