Devo mettere la traccia dello stack nei file di errore e fermare la mia app con un errore user friendly [chiuso]

1

Nel mio precedente progetto ho scritto un'app che viene utilizzata internamente. La mia pratica abituale è quella di catturare errori / eccezioni da classi e thread diversi e inserirli in file di log diversi corrispondenti a classi e thread diversi raggruppati logicamente. E alcuni errori semplificati sono stati indirizzati all'area di testo nell'interfaccia utente. Quindi all'utente viene presentata solo una spiegazione degli errori semplificata per l'utente. E quando l'app si è bloccata / bloccata, ho semplicemente usato per recuperare i registri dettagliati e scoprire cosa stava andando a rovinare dalla traccia dello stack. Questo mi ha permesso di diagnosticare il problema in modo rapido e preciso molte volte.

Ora sono in un nuovo progetto e le persone qui non stampano affatto la traccia dello stack in nessun file. Semplicemente scrivono cosa sta andando storto in alcuni file, e controlla quei file in hang up e indovina cosa potrebbe essere sbagliato. Potrebbero essere in grado di farlo, dal momento che gestiscono questo software a lungo e il loro lavoro di indovinare funziona molte volte. Ma questo non è possibile per me, dal momento che sono nuovo in questo progetto e non posso indovinare nulla.

Quindi la domanda si riduce a molte piccole domande:

  1. L'inserimento della traccia di stack nei file è sbagliato? Dal momento che scrivere su file non ha nulla a che fare con UX, è solo questo problema di sicurezza che fa sembrare una cattiva idea?
  2. Se la risposta alla prima domanda è Sì, allora il concetto di stacktrace deve essere usato solo durante il tempo di sviluppo?
  3. Se la risposta alla prima domanda è Sì, allora è un modo saggio per inserire messaggi di errore semplificati nei file e poi indovinare?
  4. Quali sono gli approcci standard seguiti nel settore?
posta Mahesha999 03.08.2015 - 09:37
fonte

1 risposta

3

Is putting stack trace in files is bad? Since writing to files has nothing to do with UX, is just that security issue that makes it look bad idea?

No, non è una brutta cosa. È una buona cosa.

Gli errori fatali richiedono log e informazioni coerenti e chiari per tentare di riprodurre l'errore, verificare l'errore visto, il triage, la risoluzione e quindi il test. A seconda dell'ambiente di destinazione, i crash dump non sono sempre possibili o fattibili. I log focalizzati sullo sviluppatore sono molto utili.

Mi aspetto che ci siano alcune cose nel registro, tra l'altro;

  • Traccia stack (dove)
  • L'errore o l'eccezione effettiva (che cosa)
  • Eventuali eccezioni interne (come)
  • Valori argomento della funzione (quando)
  • Probabilmente i diritti utente (chi)
  • Data e ora per riferimenti incrociati
  • Probabilmente una descrizione utente di ciò che stavano facendo, questo potrebbe essere legato alla registrazione del bug report

Nel problema di sicurezza, se nel registro sono presenti dati sensibili, sarà necessario disinfettarlo o crittografarlo. Gestisci la sicurezza, ma non lasciare che oscuri l'errore.

I file di dump di crash e ilk sono un concetto ben noto. Usali con giudizio e sono molto utili e utili.

    
risposta data 03.08.2015 - 09:49
fonte