Interesting; that is a problem I have seen before when using an IDataReader, which is why I now religiously consume all the tables (even if I am only expecting one) - for example, if I am only expecting one table, something like:
while (reader.Read())
{ // read data from first table
}
// read to end of stream
while (reader.NextResult()) { }
The problem is that the error goes into the TDS at the point you raise it; so if you raise it after the SELECT then in follows table in the TDS - and if the reader doesn't read to the end of the stream they might not see it.
I'll be honest - my preferred answer to this is: raise all errors before data. This might mean doing the main SELECT into a temp-table (#table) or table-variable (@table). Beyond that - if it is critical to catch this error (and if the inbuilt LINQ-to-SQL code isn't helping), then perhaps fall back to ExecuteReader and something like the above.
I suspect (but I haven't checked) that you could also use DataContext.Translate<T> to do some of the ORM heavy-lifting; for example:
// cmd is our DbCommand, and ctx is our DataContext
using(var reader = cmd.ExecuteReader()) {
var result = ctx.Translate<MyResultType>(reader).ToList();
while(reader.NextResult()) {}
return result;
}