Pregunta

Estoy creando una biblioteca "común" para ser utilizada como referencia en varios proyectos de solución por otros miembros del equipo. Los métodos son típicamente void Funciones sin datos reales devueltos.

Estoy buscando un por qué forzar el uso de estos métodos dentro de un Try...Catch Bloque de otros. Necesito asegurarme de que los errores se manejen correctamente. Pensé sobre confiar en un tipo de retorno booleano, pero eso no me permitirá devolver el mensaje de error también, por lo que mi única opción es lanzar un Exception.

Si el forzamiento adecuado no es posible, ¿cómo puedo hacer un atributo que aparezca al compilar para advertir al desarrollador sobre el requisito de prueba/captura? (una especie de Obsolete atributo).

¿Algún otro enfoque mejor?

EDITAR:

Aquí está mi escenario completo:

Tengo un método de código que llama a un servicio web para actualizar un valor de forma remota. La actualización es bastante crucial. El método que sí mismo funciona bien, pero ¿qué pasa si el servicio web no es accesible? La llamada no devuelve ningún valor.

¿Fue útil?

Solución

Colocando algo dentro de un try/catch el bloque no lo hace "manejado correctamente", de hecho, en el gran mayoría De los casos, la forma correcta de manejar una excepción es dejar que burbujee al siguiente nivel. Advertencia: try/finally es mucho más común, para permitir la limpieza de recursos, pero aún más común que eso es using.

No puede hacer cumplir "y debe usarlo correctamente" en el código; Eso está implícito en cualquier API, y solo causará irritación y molestia, y obligará a las personas a estilos de codificación inapropiados e inútiles, al tiempo que le dará un completamente artificial e incorrecto sentido de que el código sea correcto.

Si desea asegurarse de que el código funcione correctamente: pruebelo.

No hay atributos que pueda usar para este escenario. Probablemente pueda crear una regla FXCOP o similar, pero por las razones anteriores: no lo recomiendo.

Otros consejos

En realidad, no haría esto, pero como una solución divertida al problema declarado, podría construir su propio tipo de excepción: una Excepción Success. Luego, lanza esta excepción al final de su método para indicar el éxito. Esto hace que el método sea bastante inutilizable sin alguna forma de try/captación. Pero otra vez: No hagas esto.

Puede devolver una clase de resultados personalizado:

public class Result
{
    public bool Okay { get; set; }
    public string Error { get; set; }
}

Después:

var result = AttemptSomething();

if (!result.Okay)
{
    Console.WriteLine(result.Error);
}

O tal vez regresa string:

var error = AttemptSomething();

if (!String.IsNullOrEmpty(error))
{
    Console.WriteLine(error);
}

O tener el error como una salida:

string error;
if (!AttemptSomething(out error))
{
    Console.WriteLine(error);
}

O regresar Exception pero no lanzar.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top