Validere funksjonsargumenter?

stemmer
4

På regelmessig basis, jeg validere funksjonsargumenter:


public static void Function(int i, string s)
{
  Debug.Assert(i > 0);
  Debug.Assert(s != null);
  Debug.Assert(s.length > 0);
}

Selvfølgelig kontrollene er gyldig i sammenheng med funksjon.

Er dette vanlig praksis i bransjen? Hva er vanlig praksis når det gjelder funksjonsargument validering?

Publisert på 04/02/2009 klokken 20:42
kilden bruker
På andre språk...                            


9 svar

stemmer
-2

Jeg vil ikke snakke med industristandarder, men du kan kombinere de to nederste hevder i en enkelt linje:

Debug.Assert(!String.IsNullOrEmpty(s));
Svarte 04/02/2009 kl. 20:47
kilden bruker

stemmer
-1

Jeg prøver å ikke bruke Debug.Assert, heller jeg skriver vakter. Hvis funksjonen parameteren ikke er forventet verdi, avslutter jeg funksjonen. Som dette:

public static void Function(int i, string s)
{
    if(i <= 0)
    {
        /*exit and warn calling code */
    }
}

Jeg finner dette reduserer mengden av krangel som trenger å skje.

Svarte 04/02/2009 kl. 20:47
kilden bruker

stemmer
1

Mesteparten av tiden jeg bruker ikke Debug.Assert, ville jeg gjøre noe som dette.

public static void Function(int i, string s)
{
  if (i > 0 || !String.IsNullOrEmpty(s))
         Throw New ArgumentException("blah blah");
}

ADVARSEL: Dette er luft-kode, havn't jeg testet den.

Svarte 04/02/2009 kl. 20:51
kilden bruker

stemmer
3

Du bør ikke bruke hevder å validere data i en live-program. Det er min forståelse at erkjenner å er ment å teste om funksjonen blir brukt på riktig måte. Eller at funksjonen returnerer den riktige verdien Dvs verdien du får er det du forventet. De brukes mye i testing rammeverk. De er ment å være slått av når systemet er utplassert som de er treg. Hvis du ønsker å håndtere ugyldige tilfeller bør du gjøre det eksplisitt som plakaten ovenfor nevnt.

Svarte 04/02/2009 kl. 20:53
kilden bruker

stemmer
2

Enhver kode som er oppsigelige over nettverket eller via interprosess kommunikasjon absolutt må ha parameter validering fordi ellers er det et sikkerhetsproblem - men du må kaste et unntak Debug.Assert bare ikke vil gjøre, fordi det bare sjekker debug bygger.

Enhver kode som andre folk på laget ditt vil bruke også bør ha parameter valideringer, bare fordi det vil hjelpe dem vet at det er deres feil når de passerer du en ugyldig verdi, igjen bør du kaste unntak denne gangen fordi du kan legge en fin beskrivelse ot en unntak med forklaring på hva de gjorde galt og hvordan det kan løses.

Debug.Assert i funksjonen er bare for å hjelpe deg med å feilsøke, det er en fin første forsvarslinje, men det er ikke "ekte" validering.

Svarte 04/02/2009 kl. 20:53
kilden bruker

stemmer
10

Den aksepterte praksisen er som følger hvis verdiene ikke er gyldige eller vil føre til et unntak senere:

if( i < 0 )
   throw new ArgumentOutOfRangeException("i", "parameter i must be greater than 0");

if( string.IsNullOrEmpty(s) )
   throw new ArgumentNullException("s","the paramater s needs to be set ...");

Så listen over grunnleggende argument unntakene er som følger:

ArgumentException
ArgumentNullException
ArgumentOutOfRangeException
Svarte 04/02/2009 kl. 20:53
kilden bruker

stemmer
5

Det du skrev er forutsetninger , og et viktig element i design av kontrakt . Google (eller "Stackoverflow" :) for dette ordet, og du vil finne ganske mye god informasjon om det, og noen dårlig informasjon, også. Merk at metoden omfatter også postconditions og begrepet klasse invariant .

La oss la det klart at påstandene er en gyldig mekanisme.

Selvfølgelig, de er vanligvis ( ikke alltid ) ikke sjekket i versjon modus, så dette betyr at du må teste koden før du slipper den.

Hvis påstandene er igjen aktivert og en påstand er brutt, standard oppførsel i noen språk som bruker påstander (og i Eiffel spesielt) er å kaste en påstand brudd unntak.

Påstander venstre ukontrollert er ikke praktisk eller tilrådelig mekanisme hvis du publiserer en kode bibliotek, eller (selvsagt) en måte å validere direkte muligens feil inngang. Hvis du har "muligens feil input" du må designe som en del av den normale oppførselen til programmet en validering av inndata lag ; men du kan fortsatt fritt bruke påstander i de interne modulene.


Andre språk, som Java, har mer av en tradisjon for eksplisitt å sjekke argumenter og kaster unntak hvis de er feil , hovedsakelig fordi disse språkene ikke har en sterk "hevde" eller "design av kontrakten" tradisjon.

(Det kan virke merkelig for noen, men jeg synes forskjellene i tradisjon respektabel, og ikke nødvendigvis onde.)

Se også denne beslektet spørsmål .

Svarte 04/02/2009 kl. 20:59
kilden bruker

stemmer
2

For offentlige funksjoner, spesielt API-kall, bør du være å kaste unntak. Forbrukerne vil trolig sette pris på å vite at det var en feil i koden sin, og et unntak er den garantert måte å gjøre det på.

For interne eller private funksjoner, er Debug.Assert fine (men ikke nødvendig, IMO). Du vil ikke bli tatt i ukjente parametre, og testene skal fange eventuelle ugyldige verdier av forventet produksjon. Men, noen ganger, vil Debug.Assert la deg fokusere på eller hindre en bug som mye raskere.

For offentlige funksjoner som ikke er API-kall, eller interne metoder underlagt andre folk ringer dem, kan du gå begge veier. Jeg foretrekker vanligvis unntak for offentlige metoder, og (vanligvis) la interne metoder gjøre uten unntak. Hvis en intern metode er særlig utsatt for misbruk, og et unntak er berettiget.

Mens du ønsker å validere argumenter, trenger du ikke ønsker 4 nivåer av bekreftelse på at du har å holde i sync (og betale perf straffen for). Så, validere på det eksterne grensesnittet, og bare stole på at du og dine medarbeidere er i stand til å ringe virker hensiktsmessig og / eller rette opp en feil som uunngåelig resultat.

Svarte 04/02/2009 kl. 21:00
kilden bruker

stemmer
1

Du bør bruke Assert å validere programma forutsetninger; det vil si for situasjonen der

  1. du er den eneste ringer som metode
  2. det bør være en umulig tilstand for å komme inn

De Assert uttalelser vil tillate deg å dobbeltsjekke at det umulige staten er aldri nådd. Bruk dette hvor du ellers ville føle seg komfortabel uten validering.

For situasjoner der funksjonen er gitt dårlige argumenter, men du kan se at det ikke er umulig for det å motta disse verdiene (for eksempel når noen andre kan kalle denne koden), bør du kaste unntak (a la @Nathan W og @Robert Paulson ) eller mislykkes grasiøst (a la @Srdjan Pejic ).

Svarte 04/02/2009 kl. 21:01
kilden bruker

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more