Passa un ErrorMessage da inserire nel metodo di ricezione come anti-pattern?

Question

Passa un ErrorMessage da inserire nel metodo di ricezione come anti-pattern?

#1 da (1 voti)
#2 da (1 voti)

1

Vengo da uno sfondo Java e il mio collega è di .NET. Stiamo lavorando su un progetto Java e l'ho visto creare un metodo come questo:

public Object myMethod(Object[] param1, ErrorMessage errorMessage) {...}

ErrorMessage è un oggetto auto-definito che contiene solo String e viene selezionato se vuoto o non nel chiamante.

Mi sono imbattuto in questi anni fa e sono abbastanza sorpreso di vederlo di nuovo ora. Sono più propenso a lanciare un RuntimeException , ma di nuovo la clausola try-catch non fa la stessa cosa di if(!errorMessage.isEmpty()) ?

È un anti-modello? Come si chiama? Sento di essere mal equipaggiato per argomentare il mio punto di vista, e quindi il codice rimane solo lì, mi perseguita.

anti-patterns api-design java design-patterns exceptions

posta lemuel 11.10.2018 - 22:44

fonte

2 risposte

Leggi altre domande sui tag anti-patterns api-design java design-patterns exceptions

Architettura di cipolla, architettura di progetto e autenticazione Come aggiornare la versione quando vengono aggiornate solo le dipendenze?

score 1 · Answer 1

L'unico utilizzo a cui posso pensare per un pattern come questo è se myMethod contiene un codice boilerplate che esegue un'operazione con param1 , e quindi richiede errorMessage se l'operazione fallisce.

Avendolo contenuto in un metodo, si DEANALIZZA il codice boilerplate, quindi i chiamanti di myMethod devono solo specificare param1 & errorMessage invece di ripetere il boilerplate.

Tuttavia, questo non sembra essere il caso che hai descritto. Verifica se errorMessage non è vuoto & quindi gestire i suoni di errore mi sembra un tentativo / cattura più adatto.

score 1 · Answer 2

Provenendo da me stesso da Java, capisco la tua confusione. Tuttavia, questo può essere perfettamente valido se il messaggio di errore in arrivo fa parte del metodo .

Nel senso che, se dovessi dire, elaborare una risposta da una chiamata http, questo potrebbe essere un modo perfettamente legittimo di gestire una risposta al chiamante. In caso di errore, rispondere con il codice 401, altrimenti 200, ad esempio.

L'errore passato al metodo in questo caso è puramente un parametro come un altro.

Sarei più preoccupato della preferenza del tuo collega per rappresentare un errore come ErrorMessage . Se la possibilità di un errore è autenticamente eccezionale , dovrebbe essere un'eccezione e non un'istanza di un messaggio di errore. Di nuovo, anche questo potrebbe essere corretto se c'è una strong possibilità che ci sia un errore (non eccezionale).

In conclusione, sembra che ci sia qualcosa di sbagliato qui, è preferibile non usare le eccezioni per gestire gli errori. Le eccezioni sono costose, ovviamente, ma finché non si utilizzano le eccezioni come mezzo per trasmettere messaggi nel proprio programma, sono perfettamente valide e dovrebbe essere utilizzate in questi casi.