Convenzione per la registrazione all'interno dei blocchi di cattura annidati

Question

Convenzione per la registrazione all'interno dei blocchi di cattura annidati

#1 da (4 voti)
#2 da (1 voti)
#3 da (0 voti)

0

Ho esaminato questa domanda ma in realtà non aiuta a risolvere il mio dilemma.

Sistema 1 chiama il sistema 2 all'interno di un catch di prova, il metodo nel sistema 2 ha il suo proprio try catch, che gestisce purtroppo un'eccezione ma non la rilancia. Quindi la mia domanda è: quale sistema dovrebbe registrarlo? Ogni sistema ha i propri file di registrazione.

Esempio:

Class System1{
Public void DoSomething(){
    Try{
        var sys = new System2();
        sys.ExecuteMethod();
    }
    Catch{Exception e){
        logger.log(e);
    }
}
}
// ------IN A DIFFERENT SYSTEM ON A DIFFERENT MACHINE------
Class System2{
Public void ExecuteMethod(){
    Try{
        throw new Exception("Test Excpetion");
    }
    Catch{Exception e){
        logger.log(e);
    }
}
}
}

c# conventions logging exception-handling

posta MegaMark 03.02.2015 - 17:54

fonte

3 risposte

1

Si potrebbe sostenere che entrambi dovrebbero registrarlo.

Il sistema 1 sta tentando di realizzare qualcosa ma deve accedere al Sistema 2. Il sistema 1 dovrebbe registrare che non è riuscito a completare il suo lavoro per qualche motivo a causa della sua dipendenza dal Sistema 2. Se il Sistema 2 rileva un errore interno elaborando una richiesta, dovrebbe registrare anche questi tipi di problemi.

Sorgono altri casi d'uso, tra cui l'autorizzazione, la connettività di rete, le richieste errate, ecc. Considerare ciascuno e il modo in cui ogni sistema dovrebbe (se necessario) registrarlo.

risposta data 03.02.2015 - 18:13

fonte

0

Dipende dall'eccezione. Se ti aspetti che l'eccezione possa verificarsi ed è valida, e tu la stai effettivamente trattando , come in, hai il piano B per quella situazione, quindi non buttarlo.

Se l'eccezione interrompe il flusso di lavoro e in realtà non lo stai gestendo, procedi e registralo se lo ritieni necessario, ma a volte l'ambito del metodo corrente non ha abbastanza informazioni utili per giustificare la registrazione. A volte vorrai lanciarlo a un livello più alto con più informazioni utili, prenderlo lì, quindi registrarlo.

Ad esempio:

int DoSomething1(int userId, int transactionId) {
    try {
        int orgId = GetOrgId(userId);
        DoSomething2(orgId);
        /* ... more things ... */
    } catch(MyException ex) {
        Log(string.Format("{0}\nuser: {1}, trns: {2}\n\tMessage: {3}\n\t\tTrace: {4}", 
            ex.Message, userId, transactionId, ex.InnerException.Message, ex.InnerException.StackTrace));
        throw;
    } catch(Exception ex) {
        Log(string.Format("user: {0}, trns: {1}\n\tMessage: {2}\n\t\tTrace: {3}", 
            userId, transactionId, ex.Message, ex.StackTrace));
        throw;
    }
}

int DoSomething2(int orgId) {
    try {
        /* ... some stuff .... */
    } catch(Exception ex) {
        throw new MyException { Message = string.Format("org: {0}", orgId),
            InnerException = ex };
    }
}

Il tuo front-end non dovrebbe scaricare le tracce dello stack per gli utenti, quindi se l'eccezione arriva così lontano, devi gestirlo in un modo o nell'altro. Ma questo dipende da cosa è il front-end. Se si tratta di un servizio web, i codici di errore sono molto belli invece di fingere ingannevolmente che tutto è andato a buon fine, o non dare loro alcun feedback.

risposta data 03.02.2015 - 18:40

fonte

Leggi altre domande sui tag c# conventions logging exception-handling

Qual è il nome di un tipo definito da un modello? [chiuso] Come trattare con il proprietario del prodotto che si rifiuta di seguire le regole di progettazione dell'interfaccia utente

score 4 · Accepted Answer

Se il sistema 2 gestisce l'eccezione e non la rilancia, sembra che il sistema 1 non abbia modo di sapere che si è verificata un'eccezione. In tal caso, non c'è davvero alcun dubbio sul fatto che il sistema 1 debba registrare qualsiasi cosa, poiché non sa che si è verificato un errore!

Se entrambi i sistemi sono a conoscenza dell'errore, e stanno registrando in posti diversi, e l'errore è qualcosa che si desidera registrare, allora probabilmente dovresti avere entrambi di registro l'errore. Potresti voler pensare a trovare un modo per unificare la registrazione, dato che i file di log multipli sono difficili da setacciare (a meno che non si tratti di un sistema client / server in cui il sistema 2 è in esecuzione su una macchina diversa dal sistema 1, allora vuoi per accedere in entrambi i posti).

Se il sistema 2 gestisce legittimamente l'errore, probabilmente non è necessario registrarlo nel sistema 1. Potrebbe anche non esserci un motivo per collegarlo nel sistema 2, ma è necessario analizzare se è necessario per la tua situazione.

In genere consiglio che, in caso di dubbio, registrarlo. Ma sicuramente vuoi controllare ad un certo punto se stai registrando troppe informazioni, preferibilmente prima di andare in produzione.