Quali sono i pro e i contro di convalidare il tuo compito previsto?
public static bool UploadFile(string filename)
{
// 1. upload the file
// 2. check to see if the file now exist on the server and return status
}
vs.
public static void UploadFile(string filename)
{
// 1. upload the file and hope it's on the server now, or check with another method to see if the file exist on the server
}
Il tuo esempio è imperfetto.
Quando si carica un file sul server, se si verifica qualcosa di sbagliato, come un timeout o un errore sul lato server, ciò comporterebbe un'eccezione. Se questo non si risolve in un'eccezione, i metodi sottostanti che stai utilizzando che non ne hanno gettato sono un problema, e dovresti passare a una libreria che fa le cose correttamente.
Ad esempio, se la libreria HTTP che usi non getta nulla quando riceve HTTP 500 dal server, la libreria fa schifo. Usane uno migliore.
Questo significa anche che entrambi i tuoi pezzi di codice sono sbagliati.
Nel primo caso, non si controlla se il file esiste. Esiste, ovviamente, perché hai appena caricato il file e il server ha restituito un HTTP 201 che è stato elaborato dalla libreria HTTP sottostante come risposta positiva. Se non esiste, non dovresti raggiungere il secondo punto del tuo metodo, perché dovrebbe essere stata generata un'eccezione.
Nel secondo caso, non sperare che qualcosa funzioni. Sai che funziona.
public static void UploadFile(string filename)
{
// 1. Upload the file.
// 2. The file is uploaded. It's there, on the server.
}
Dal modo in cui la tua domanda è formulata, sembra che tu stia chiedendo genericamente se dovresti verificare che qualcosa sia stato eseguito correttamente. La risposta è sì.
Se è qualcosa di semplice come una chiamata di sistema, restituirai il codice di uscita del runtime Ad esempio:
Runtime.exitValue()
Questo presume che qualunque cosa tu abbia eseguito, restituisca un errore appropriato. Se eseguo uno script Bash da Linux e restituisce 2, il codice Java deve sapere cosa significa e cosa fare.
In Java le cose più importanti da prendere sono le eccezioni (e NON le si limitano a considerarle come eccezioni generiche). ArithmeticException (dividendo per 0), ArrayOutOfBounds (accesso a parte di un array che non è definito), NullPointer, ecc. Ogni volta che si imbattono in comportamenti inaspettati o rischiosi, è sempre più sicuro prendere te stesso.
Il grado di verifica durante la verifica varia nel tuo ambiente di sviluppo.
Leggi altre domande sui tag testing encapsulation c# design-patterns