Ho il seguente:
public class doCheck(){
public void performCheck(){
try {
perform all checks......
}
catch(Exception e){
logger.error("Exception occured in class doCheck in method performCheck");
thrown new MyNewException(e.getMessage());
}
}
}
È sicuro registrare il nome della classe e del metodo?
Dipende dal fatto che il tuo codice base sia nascosto o meno. Se spedisci il prodotto al cliente, allora può ispezionare il codice byte Java in modo insignificante, quindi i nomi delle classi di registrazione non rivelano alcuna informazione che l'utente non può ottenere comunque.
Per un'applicazione lato server, questo è ancora vero. Tuttavia, potrebbe essere un buco di sicurezza per visualizzare tali registri sul client. Ecco perché la maggior parte dei framework di applicazioni Web distingue tra una configurazione di sviluppo e di produzione: durante lo sviluppo, le informazioni di debug vengono visualizzate all'utente in caso di errore. In produzione, queste informazioni vengono registrate sul server, ma non vengono più visualizzate nel browser web / sul client.
@Konrad ha risposto alla domanda diretta, tuttavia la gestione delle eccezioni ha un problema minore e due gravi. Dato che hai originariamente pubblicato su codereview.SE, eccoli qui:
OK, ho intenzione di aggiungere un quarto problema: si registra dove si è verificata l'eccezione, ma non si dice cosa si stava facendo quando è successo, o si fornisce alcuna informazione contestuale. Se registri l'eccezione vera e propria (punto 1), saprai dove è successo. Più importante è dire qualcosa come "impossibile aprire il file foo.txt".
Non è particolarmente pericoloso, quindi a meno che non ci sia qualcosa di critico da nascondere in questa classe o se la classe fa parte di un percorso critico (come una stretta di mano sicura o una funzionalità "nascosta"), non prenderei in considerazione questo è un problema.
Inoltre, stiamo parlando di Java qui. Quindi, se stiamo parlando di un'app lato client che esegue Java sul client, possono sempre modificare il loro JRE per utilizzare le loro routine di debug e / o usare un classloader personalizzato e accedere alle classi praticamente in qualsiasi modo. Rendere più difficile per loro (nascondendo il codice più profondo, o addirittura offuscando il codice) è sempre una possibilità, ma di solito non è economicamente conveniente se si considera il tempo e lo sforzo necessari per raggiungere questo obiettivo contro la perdita causata da statistiche statisticamente improbabili utenti malintenzionati.
Se stiamo parlando di una parte del software lato server che può generare log per i client (ad esempio, per il browser dell'utente), allora probabilmente non è un affare troppo grande, ma è già più semplice da risolvere: configurare il contenitore di conseguenza, e utilizzare un framework di registrazione o multiplexer per l'output su file appropriati sul server per scopi di debug invece. In questo modo puoi conservare i record utili per il debug ma non compromettere le informazioni potenzialmente utili.
Ma in generale, questo probabilmente non sarebbe un problema. è più quello che metti nel messaggio di debug che potrebbe essere un problema, dato che tendiamo spesso come sviluppatori a generare le cose su cui lavoriamo (non vuoi lasciare questi output di debug per nomi utente, password, sali e token di sicurezza in chiara visione ).
Leggi altre domande sui tag java security exception-handling