¿Existe alguna excusa para generar una excepción a partir de una conversión implícita?

Question

De MSDN:

Al eliminar conversiones innecesarias, las conversiones implícitas pueden mejorar la legibilidad del código fuente.Sin embargo, debido a que pueden ocurrir conversiones implícitas sin que el programador las especifique, se debe tener cuidado para evitar sorpresas desagradables.En general, los operadores de conversión implícitos nunca deben generar excepciones y nunca perder información para que puedan usarse de manera segura sin que el programador se dé cuenta.Si un operador de conversión no puede cumplir con esos criterios, debe marcarse como explícito.

Si bien no estoy en desacuerdo con ningún punto en particular, y estoy de acuerdo en que todo esto es muy bueno, ¿existe alguna vez una razón lo suficientemente importante como para justificar romper la parte sobre conversiones implícitas que no generan excepciones?

El caso particular que tengo ante mí es uno en el que:

1. Tengo una función que devuelve un objeto de colección personalizado (lo llamaremos FooCollection).
2. Esta función puede devolver colecciones con un solo artículo, y Se puede determinar a partir del código fuente si esto sucederá o no..(con esto me refiero solo a la llamada a la función, no a la función en sí)
3. Si esto sucede, hay un 99,9% de probabilidad de que el usuario quiera ese único artículo, en lugar de una colección con un solo artículo.

Ahora, estoy dudando si incluir una conversión implícita de FooCollection => Foo para ocultar este pequeño detalle de implementación, pero esta conversión solo funcionará si hay un solo elemento en la colección.

¿Está bien lanzar un Exception ¿en este caso?¿O debería utilizar una conversión explícita en su lugar?¿Alguna otra idea sobre cómo podría lidiar con esto (no, debido a los detalles de implementación no puedo usar solo dos funciones)?

EDITAR: Siento que es digno de notar que FooCollection no implementa ninguna interfaz ni realmente extiende Collection como su nombre podría implicar, por lo tanto, las respuestas basadas en LINQ son inútiles.Además, si bien la colección implementa un índice numérico, no es la forma más intuitiva de manejar la colección, ya que se basa principalmente en un índice con nombre.

Answer 1

Estoy con las pautas:Nunca deberías descartar una conversión implícita.

Definitivamente no proporcionaría una conversión implícita en este caso.Incluso la idea de un reparto explícito me parece incorrecta: Foo x = (Foo)fooCollection simplemente no parece correcto.

¿Por qué no dejas que el código de llamada se preocupe por la conversión de FooCollection a Foo?El código sería mucho más intuitivo para todos:

Foo a = fooCollection[0];
Foo b = fooCollection.First();
Foo c = fooCollection.FirstOrDefault();
// etc

Answer 2

Es evidente que no está bien. Nunca excepciones utilizar para implementar la lógica!

Puede utilizar el FooCollection.FirstOrDefault() LINQ Declaración, lo que dará nulo o el primer elemento.

Answer 3

El molde debe ser explícita. Va a ser muy extraño para ser capaz de asignar un FooCollection a un Foo sin al menos un molde.

Una vez dicho esto, en mi humilde opinión moldes no son una buena manera de hacer esto. Incluso si no a que diga que voy a utilizar una función porque incluso si usted no tiene control sobre la aplicación de estas clases, al menos puede agregar extensiones de métodos como Foo ToFoo(this FooCollection collection) a hacer el trabajo.

Answer 4

Una copnversion implícita de que sólo funciona si hay sólo 1 elemento de la colección? Así que, de hecho, no funciona la mayor parte del tiempo?

Yo nunca hacer esta conversión implícita. Seguir con explícita. Si el programador usando la función quiere tener el elemento único, que sólo debe decirle a su clase.