Dapper Doesn't throw an exception when no property or field exists to map column to

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Run a query that returns multiple columns
2. Map the result to a POCO that does not have properties for all the columns 
in the query

Expected: Dapper throws an exception
Actual: Dapper ignores columns that cannot be mapped to columns.

Looking at the source code it seems like this is the intended behavior, in my 
current deployment I've implemented the exception throwing by building a custom 
ITypeMap implementation but it feels very hacky and is highly dependent on the 
internal behavior of dapper (which I don't like).
While I think the use case of POCO properties that don't have corresponding 
columns makes sense I don't think there's as much value in columns that don't 
have POCO properties - in fact the most common case I can think of is when I've 
spelled the name of a property wrong. Does it make sense to modify the 
GetTypeDeserializer Method to throw an exception in the case that there is no 
property to map an output to?

Original issue reported on code.google.com by Chris.Pa...@gmail.com on 26 Sep 2013 at 2:40

[GoogleCodeExporter]

It is explicitly not intended that extra columns cause an exception. This 
behaviour is intentional and deliberate, and indeed: changing it without an 
option would cause lots of problems. This could *potentially* be made an opt-in 
thing, but I'm not sure what problem it solves... can you clarify when this is 
an issue?

Original comment by marc.gravell on 26 Sep 2013 at 9:46

[GoogleCodeExporter]

For example if I have the class and query

 class Product
 {
     public long Id {get; set;}
     public string Description {get; set;}
     public int ListPrice {get; set;}
 }

 SELECT p.[Id], p.[Description], pc.[Price] as [ListPriec]
 FROM Product p
 JOIN PricingCatalog pc ON pc.[ProductId] = p.[Id]
 WHERE pc.[CatalogId] = @CatalogId

Because I spelled the name of a property wrong in my query ListPrice will be 
defaulted to 0 on all the objects returned. It will be much easier to catch 
this if I get an exception along the lines of "No matched Property for column 
ListPriec" rather than simply having all product prices be 0.
That being said seeing as this is the intended behavior what is the use case in 
which it makes sense? I agree that this isn't something that could be safely 
done as the default, maybe a "strict mode" option when calling Query that let 
Dapper do more validation would make sense?

Original comment by Chris.Pa...@gmail.com on 26 Sep 2013 at 11:47

[GoogleCodeExporter]

The classic time where we do not want it to break is simply: the database 
returns info we don't care about. This could be because somebody edits a stored 
procedure to return additional info, or it could be because it is a "select *", 
and a column gets added. We *also* don't object if the object has properties 
that do not have corresponding columns. Basically, it will map anything that 
matches. Anything else should IMO be handled by your local integration tests...

Original comment by marc.gravell on 26 Sep 2013 at 12:29