tengo un método que se puede escribir muy cuidadosamente a través del método de encadenamiento:método de encadenamiento de LINQ y error granular manejo
return viewer.ServerReport.GetParameters()
.Single(p => p.Name == Convention.Ssrs.RegionParamName)
.ValidValues
.Select(v => v.Value);
Sin embargo, me gustaría ser capaz de hacer algunas comprobaciones en cada punto como deseo brinde información de diagnóstico útil si alguno de los métodos encadenados arroja resultados inesperados.
Para lograr esto, necesito dividir todo mi encadenamiento y seguir cada llamada con un bloque if
. Hace que el código sea mucho menos legible.
Idealmente, me gustaría poder realizar algunas llamadas a métodos encadenados que me permitan manejar resultados inesperados en cada punto (por ejemplo, arrojar una excepción significativa como new ConventionException("The report contains no parameter")
si el primer método devuelve una colección vacía). ¿Alguien puede sugerir una manera simple de lograr tal cosa?
Editar:
Este es el resultado del uso de @ respuesta de JeffreyZhao:
return viewer.ServerReport.GetParameters()
.Assert(result => result.Any(), "The report contains no parameter")
.SingleOrDefault(p => p.Name == Convention.Ssrs.RegionParamName)
.Assert(result => result != null, "The report does not contain a region parameter")
.ValidValues
.Select(v => v.Value)
.Assert(result => result.Any(), "The region parameter in the report does not contain any valid value");
Esto se ve bien. Y dada la naturaleza de la comprobación de errores, sospecho que puede ser que los métodos genéricos no sean necesarios (es decir, a menudo la naturaleza de la comprobación de errores es específica para un tipo dado). El enfoque general de tener un método de extensión que simplemente devuelve la entrada sin modificar es exactamente lo que se necesita. – Chris
Tienes razón.Agregué un método 'Validate' más general y en ese caso se requiere el genérico. –
Agradable. Ojalá pudiera +1 de nuevo para esa pequeña y agradable función 'Validate'. :) – Chris