Mi sono imbattuto in questo mentre modificavo una vecchia applicazione ASP:
ON ERROR RESUME NEXT
ivalue = CDATE(ivalue)
IF err.number > 0 THEN
ivalue = CDATE(date)
END IF
err.clear
Questo non sembra una buona pratica. Qual è lo scopo di farlo in questo modo, e c'è un modo migliore per farlo? Ad esempio, avrei appena usato ISDATE() : c'è qualcosa che mi manca?
In alcuni casi (a seconda dell'API, ecc.) è più facile provare qualcosa e controllare il risultato (prendere un'eccezione o qualsiasi altra cosa) piuttosto che controllare il parametro; Non sono sicuro del programma VB dato, ma se è un caso comune che ivalue non è un parametro valido per CDATE , allora è meglio farlo come nell'esempio, cioè ON ERROR RESUME NEXT , e controllare err.number, invece di lasciare che CDATE generi un'eccezione e la cattura. Perché le eccezioni sono solo per circostanze eccezionali.
Le versioni precedenti del classico VB non ti lasciavano molto altro con cui lavorare. Nel tuo esempio potresti provare ad analizzare manualmente l'imput manualmente, ma le prestazioni su questo tipo di codice di errore erano in genere molte volte sufficienti per l'analisi manuale e tryparse era qualcosa che non era ancora disponibile.
Il controllo e il recupero dal valore errato dopo aver saltato il passato con il curriculum successivo piuttosto che semplicemente arare avanti era comunque un segno di un buon sviluppatore al momento.
Pensavo che Error Driven Development fosse:
1) Ottieni il codice di errore.
2) Digita Google e trova la soluzione.
3) Implementa la soluzione.
Se si utilizzano le eccezioni per il conteggio del controllo di flusso, allora sì: - (((
Abbiamo codice nella nostra app legacy che - in cima alla mia testa - assomiglia a qualcosa del genere:
class SomewhereDeepInTheCallHierarchy {
...
public void longAndObscureMethod(...) {
...
for (...) {
String someValue = getFieldValueFromServerTransactionResponse(...);
// lots of code...
if (someValue.equals(...)) ...
}
...
}
...
}
class MuchHigherLevel {
...
public void someMethod(...) {
...
try {
...
callLongAndObscureMethodIndirectly();
...
} catch (NullPointerException e) {
logger.info("Caught null pointer exception from longAndObscureMethod"
+ " because all field values from transaction X have been processed");
doTheNextProcessingStep();
}
}
...
}
Leggi altre domande sui tag error-handling asp-classic