Why won't fix query.Sum() on empty query?

[linmo...@gmail.com]

Hi guys,

I get an exception saying "Value cannot be null" when i execute this query (NH 3.3.3):

var total = query.Sum(x => x.Income);

The exception happens when the query returns no result.

I found there's already a Jira issue about this: 

https://nhibernate.jira.com/browse/NH-3113 

But why won't fix? It's really not usable if this query throws exception. In every application that need to do reporting will encounter this.

And this violate the semantic of the sum and linq to objects, right? 

If this should throw exception, why query.Count() don't throws? 

(I understand the technical reason of this, just saying why the semantic of these are not consistent)

If L2S or EF behaves the same, I think it's their bug. Not because it's a good thing.

Workaounds like this "var sum = myQuery.Sum(x => (int?)x.Prop) ?? 0" make my code really ugly. 

Ideas? 

---

Mouhong

[Ricardo Peres]

var total = query.Sum(x => (double?) x.Income);

Replace double for single, int, long, etc.

By the way, the proper place to ask questions is the nhusers mailing list, not this one.

RP

[Mouhong Lin]

I already know that workaround before I created this post.

I mean why this is treat as "by design" behavior and not plan to fix it.

That's why I posted it here instead of the nhusers groupd.

[Stephen Bohlen]

I don't think its technically 'broken'.  As you can see from the comments in the JIRA issue, the final design decision was to mimic the behavior of sim. LINQ statements in other ORMs in the .NET space for the sake of consistency and so as not to violate "the principle of least-surprise".

If that behavior isn't what you seek for your use-case, then you are certainly free to apply the work-arounds discussed.  If you don't like the "ugly" syntax this produces in your code, then I recommend you create an extension method of your own ( perhaps "IEnumerable.NullSafeSum(...)" ?) and invoke that instead.

Cheers,

Steve Bohlen
sbo...@gmail.com
http://blog.unhandled-exceptions.com
http://twitter.com/sbohlen

--

---
You received this message because you are subscribed to the Google Groups "nhibernate-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nhibernate-develo...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Stephen Bohlen]

Actually, I suppose that really needs to be "NullSafeSum<T>(...)" so that you can control the casting type externally, but you take my point :)

Cheers,

Steve Bohlen
sbo...@gmail.com
http://blog.unhandled-exceptions.com
http://twitter.com/sbohlen

[Mouhong Lin]

but make it returns 0 and not throwing exception is not "surprise" right? but the exception is "surprise". If in EF user use the same workaround, when he turn to NH, that workaroud is still working, so it doesn't break anything, so there's no "surprise".

You received this message because you are subscribed to a topic in the Google Groups "nhibernate-development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/nhibernate-development/o5orsYz7Ums/unsubscribe.
To unsubscribe from this group and all its topics, send an email to nhibernate-develo...@googlegroups.com.

[Diego Mijelshon]

A SUM with no rows returns null in SQL.

You are trying to cast NULL to a non-nullable type. That's what causes the exception.

Automagically transforming null to 0 would be a bug.

Yes, this is not what happens with LINQ to objects. But LINQ is a leaky abstraction.

Diego 

[Mouhong Lin]

That make sense if it has technical reason :) I thought there's no technical reason, but just because the team want to keep the behavior same as EF.