omdanne string til int

hej du skriver bare

Convert.ToInt32(Request.QueryString["tcdid"])

Så laver den, den om til en int

Fx

int myint = System.Convert.ToInt32(Request.QueryString["tcdid"]);

Og gør noget fornuftigt ved den exception, der kommer når nogen skriver ...id=øllebrød

Takker. Ja der skal en exception på. jtoft var vist lige 9 sekunder hurtigere end erikjacobsen :-) Hvis du laver et svar så får du lidt points.

her kommer der et svar

Jeg har lige lavet denne metode til dig, som du kan benytte hvis du har lyst.
- lavede den for sjov.

Det er mest hvis du vil undgå try catch blokke over det hele.. der skal trods alt bare konverteres til en int så det er næsten sørgeligt, at det skal koste en grim try catch blok (jeg synes de er grimme).

Du kan selv lave om på den hvis du vil, men hvis du vil kalde min metode, som du kan finde i bunden skal det bare gøres sådan her.

        Nullable<Int32> number = parseInteger(Request["tcdid"]);
        Response.Write("I found : " + number ?? string.Empty);


og min metode. (jeg har ikke lige overvejet om der er situationer der ikke er taget højde for, men vil mene det hele skulle være klaret i den)

    private Nullable<Int32> parseInteger(object parameter)
    {
        Int32[] definedNumbers = new Int32[]{0,1,2,3,4,5,6,7,8,9};
        if (parameter == null) return null;
        string testSample = parameter.ToString();
        foreach (Int32 number in definedNumbers)
        {
            testSample = testSample.Replace(number.ToString(), "");
        }

        if (testSample.Trim() != "") return null;
        if (parameter.ToString().Trim().Length >= Int32.MaxValue.ToString().Length) return null;
        return Int32.Parse(parameter.ToString().Trim());
    }



og ellers kan det måske være inspiration til noget andet:P

man burde nok lige bytte om på disse linjer.

Int32[] definedNumbers = new Int32[]{0,1,2,3,4,5,6,7,8,9};
        if (parameter == null) return null;

da der ikke er nogen grund til at oprette et array hvis den alligevel returnere null lige efter.

Jeg tror du får en kedelig exception hvis du putter "3000000000" (3 milliader) ind i din funktion, kalp. Jeg har dog ikke prøvet.

erikjacobsen

nope det har jeg taget højde for lige før den sidste return:)

max value: 2147483647
længde: 10

value: 3000000000
længde: 10

samme længde, men ikke samme værdi.

Nogen grund til ikke at benytte TryParse-metoden?

ranglen

ikke andet end eksperimenterende=)

og ja der er noget om snakken med hensyn til det du lige sagde.. så der skal man også lige håndtere den problemstilling

Sådan her måske

private Nullable<Int32> parseInteger(object parameter)
{
    if (parameter == null) return null;

    Int32[] definedNumbers = new Int32[]{0,1,2,3,4,5,6,7,8,9};
    string testSample = parameter.ToString();

    foreach (Int32 number in definedNumbers)
    {
        testSample = testSample.Replace(number.ToString(), "");
    }

    if (testSample.Trim() != "") return null;

    if(parameter.ToString().Length > int.MaxValue.ToString().Length) return null;

    char[] chars = parameter.ToString().ToCharArray();
    Array.Reverse(chars);

    long mul = 1;
    long value = 0;

    foreach(char c in chars)
    {
        value += mul * ((long)(c-48));
        if(value > int.MaxValue) return null;
        mul *= 10;
    }

    return (int)value;
}

Hvorfor i alverden opfinde den dybe talærken to gange spørg jeg bare... det er da lige lovlig visionært... og ja... hvis man ikke vil arbejde med Exceptions i det her tilfælde så er TryParse jo en fantastisk metode...

Men at man ikke kan lide Try Catch blokke er sådan lidt øhhh... o.O... hvis man arbejder med fx Java eller .NET... så har man da vist valgt en forkert gren at side på... o.O...

Og så lige for at være fræk:

        #region public static Nullable<int> DummyTryParse( string number )
        /// <summary>
        ///
        /// </summary>
        /// <param name="number"></param>
        /// <returns></returns>
        public static Nullable<int> DummyTryParse( string number )
        {
            int val;
            if ( int.TryParse( number, out val ) )
                return val;
            return null;
        }
        #endregion

og den kunne gøres på 2 andre måder også... men nu er det så lige vi løber ind i den næste lort...

Hvordan behaver vi lige når vi:

int x = Program.DummyTryParse( "2" ) + Program.DummyTryParse( "asd" ); //Compile Fejl
int x = (int)Program.DummyTryParse( "2" ) + (int)Program.DummyTryParse( "asd" ); //Runtime Exception

Ja så fik vi da fjernet alt det der med exception handling... hov nej... vi flyttede bare børgen et tand og fik en mindre sigende exception...

Såe jeg ved sQ ikke Kalp... syns måske den er lidt langt ude som en løsning...

Men det er da HELT sikkert en sjov ting at lege med, og en super god opgave at give til folk der evt. er igang med at lærer at programmere (Lav din egen parsemetode uden at bruge de build in funktions)... der syntes jeg faktisk den er utrolig god... den opgave skulle naturligvis indeholde lidt mere end bare Parse til int... skulle være en opgave til Int, Long, Float, Double, Bool, ect... der kan jeg lade ideen vinde stor indpass... men ikke til funktionelt brug... sorry ;)

md_craig

Hvis man sidder om aftenen og slapper af, som jeg gør lige nu så er det primært for hyggens skyld (ja jeg hygger mig når jeg eksperimentere)

med hensyn til din kommentar angående try catch blokke så tager du utrolig fejl med den bemærkning.

Jeg vil hellere have en programmør på mine opgaver, som producere kode på en måde så en exception helst ikke kan forekomme.

Du gør det forhåbentlig selv når du skal teste om noget er null før du arbejder med det?

f.eks

if(Request["id"] != null)
//gør noget

eller programmere du sådan her?

try{
string tekst = Request["id"].ToString();
}catch{}

og jeg kan finde tusinde andre eksempler hvor man ikke skal kaste try catch rundt om og det er i alle de situationer jeg siger at den der grim.

En ulempe ved den form for kodning er, at programmet måske ikke crasher, men der er stadig en fejl! og det kan ende med et eller anden stort slutproblem.

hvis du i tvivl om hvad jeg mener og hvor jeg vil hen med det så spørger du bare..

md_craig

nej.. funktionen er fin nok forstår ikke hvad du mener med en intet sigende exception? når der ikke kommer en?

har testet

Kommentar: ranglen
18/07-2007 00:14:32

og det fungerer.

hvis man modtager "null" efter den er blevet kaldt så siger det sig selv - det er ikke en int man prøver at parse.

ps.

min pointe med min forrige kommentar er blot, at robust kode ikke nødvendigvis er kode, som har alt indrammet i try catch.. try catch skal kun bruges hvor man ikke har mulighed for, at håndtere en evt. uventet handling på andre måder og så skal den fanges.

hvis man kan styre flowed programmelt så skal også gøre det

men sikkert bare en holdningssag

Kommentar: kalp > 18/07-2007 00:36:35

Som et SUPER godt citat kan det tages at:

"Computer software is far more complex still, and with that complexity comes an increased propensity to failure. It is probably fair to say that there is not a single large piece of software or hardware today that is free of bugs."

Men en ting er sikkert... JEG VILLE ALDRIG parse en int som det du kommer med der... og vær nu lidt ærlig ikke...
det er der overhovedet ikke fornuftigt at skrive så mange liniers kode for at gøre så lidt... TryParse vil 100% være min foretrukne i denne sammenhæng...

Det har visse andre store hager det du har gang i:
- Øget komplexitet, flere tilstande programmet kan være i, flere liniers kode... det siger sig selv.
- Forringet forståelighed, den næste programmør der skal kigge på den kode der vil bruge væsentlig længere tid på at forstå hvad der sker end med en mere velforstået parse
- Du flytter ansvaret for en korekt parsemetode til dine egne skuldre... dermed en stører økonomisk belastning under fejlfinding og support.

Men jeg er uenig med dig i at Try Catch kun bruges hvis man ikke har andre muligheder...

Vi er mennesker og dermed laver vi fejl, så det er 100% sikkert at vi ikke får pakket alt ind med AssertionTests inden vi gør noget... Det er naturligvis ofte det fornuftige (så længe vi kan begrænse os til få Assertions)...
Men Vi vil altid glemme nogen nogle steder... der kan vi fint bruge exceptions, for exceptions propegere automatisk... så nogle fornuftigt placerede Try Catch blokke kan fange fejl som man ikke forudså...

Jeg er stor tilhænger af Try Catch og samtidig hader jeg også fenomenet...
Men grunden til jeg hader fenomenet er at jeg har fået meget lidt teoretisk viden om "Hvad gør vi så når det endelig sker at vi lander inde i en Catch"...
Ja... der er nemlig rigtig mange muligheder...

Er det vi har fat i en Exception-Terminate eller en Exception-Resume?
Hvor oprinder den og skal vi Propagere den videre op?
Og hvad er det i hele taget for en Exception? Domain Error, Range Error, Out-of-the-Ordinary Events eller Timing Failures (den sidste gør sig kun gældende inden for Real-time Programmering)

Osv...

nej jeg ville skam heller ikke parse en på den måde... men benytte tryparse metoden.

som jeg siger så skrev jeg det for hyggens skyld fordi det interessere mig, at kunne lave disse metoder selv og ikke bare kunne benytte faciliteter i sproget:)

og tror du har mistforstået helt hvad jeg snakker om med henyn til try catch blokke.. så prøver  med endnu et eksempel.

hvis du skal læse fra xml så er det GRIMT at skrive

try{
string xx = xmldocument.Attributes["xxx"].Value;
}catch{}

fordi du ikke altid kan være sikker på den attribut findes.

så skriver man selvfølgelig

if(xmldocument.Attributes["xxx"] != null)
string xx = xmldocument.Attributes["xxx"].Value;

men selvfølgelig ville jeg benytte en try catch blok hvis jeg f.eks skulle kalde en "Booking" metode over en webservice fra en anden udbyder så jeg kan håndtere en evt. timeout eller andet.

men der er også stor forskel fra det og at smide en try catch kun om noget så simpelt, som at parse en int!

det eneste vi åbenbart er enige om er at man bør benytte TryParse i den situation... angående TryCatch blokke har vi vel hver sin mening;)

Lad mig så prøve på en anden måde...

Lad os nu sige du har lavet den her fine "parseInteger" Metode...
Og nu skal en 3. mand bruge den...

Syns du så stadig det er smart bare at returnere null hvis indputtet så ikke kan parses, eller er det måske i virkeligheden ikke smartere at kunne fortælle ham hvad det egentlig var der gik galt?...

Så du kan fortælle ham om det var fordi at kan kom null ind i metoden? var der forkerte tegn i indputtet? eller var nummeret simpelthen for stort til a parse?

Der syntes jeg det er fornuftigt at fortælle hvad der gik galt, selv om det er ganske simple fejl vi har med at gøre... så har han pluselig mere viden om hvad der egentlig gik galt og ikke bare... jamen det her gik galt... punktum...

Her er det pluselig efter min mening at det bliver fornuftigt at raise en exception for at fortælle... hey du kom altså et for stort tal ind her (OverflowException)...

---

Som svar til at du siger det var for hyggens skyld, der sagde jeg netop at det er en skide god ide i en lære messig sammenhæng, men ikke i en funktionel sammenhæng... og det hentyder lidt til det samme...

Som svar til dit XML Haløj kan jeg så sige at jow... jeg kunne godt finde på at bruge en try catch blok i den sammenhæng... men naturligvis ikke for hver value...

Men hvis jeg havde en XML Settings fil, selv designet og jeg var sikker på at følgende parametre skulle være der:

BaudRate
DataBits
FlowControl
Parity
StopBits
Encoding

med mindre filen fra mit synspunkt var "korrupt". Så ville jeg pakke udhentningen af de værdier ind i en try catch... frem for at checke for hver eneste om den var der... hvorfor så det?... to grunde:

1 - Manglede en, ville jeg se dem alle som ubruglige (der er en fejl i instillingsfilen), og der skulle tages en anden handling... typisk informere om at indstillingsfilen er "korrupt"... og man på indstille på ny. (eller loade en backup, i såfald behøver man måske ikke informere direkte om det.

2 - At der mangler en er end "Undtagelses tilstand" og normalt ikke noget der vil ske, og en uacceptabel tilstand for alle parametre.

Var der derimod en "Normal tilstand" at der kunne mangle en eller flere parametre, så ville jeg naturligvis bruge if's istedet...

Det kommer sådan set helt an på situationen;)
Hvis jeg har lavet en side hvor jeg forventer en parameter "date" og denne ikke angives i url'en så skal jeg håndtere en "null" parameter. I sådan et tilfælde er det ikke sikkert jeg behøver informere bruger og den præcise fejl da det måske kan være nok jeg selv vælger evt. dags dato.
Det vil starte siden og han kan efterfølgende rette dato'en til det han nu gerne vil, men siden crasher ikke.
Måske ikke det bedste eksempel.
Jeg har haft anvendt mange metoder hvor jeg blot tjekker på om det metoden returnere er "null" eller "0" eller hvad der nu er status for "godt" eller "dårligt" og det har været  fint i de situationer til mine projekter.
Jeg forstår godt at du mener det er svært at vide hvad man skal gøre anderledes hvis sådan en metode fejl, men det afhænger af situationen - hvis det er dig selv som styrer hvad metoden modtager så kender du også udfaldet.


men du behøver ikke nævne den metode fra før længere... det er som sagt kun for egen hygge og lærings skyld.
Men ligepræcis det, som ranglen tilføjede ekstra er det, som gør programmering interessant for mig. (og ikke bare kun kunne anvende hvad andre har lavet for mig)

----------
    Array.Reverse(chars);

    long mul = 1;
    long value = 0;

    foreach(char c in chars)
    {
        value += mul * ((long)(c-48));
        if(value > int.MaxValue) return null;
        mul *= 10;
    }
----------

Det interessere mig, at se hvordan man kan lave disse ting - jeg bruger ALDRIG min tid på sådan noget i virkelig projekter for det er der slet ikke tid til for netop der skal det bare være der! så det kan bruges.

jeg er stadig uenig med hensyn til vores Try Catch blokke... og netop i XML er jeg stor tilhænger af "Switch" hvis jeg skal loppe et dokument igennem.

Det har ikke noget med attributter at gøre fra mit eksempel før, men det kunne ligeså godt være du prøvede at læse en "Node" som ikke findes..
Men en løkke med en switch i der håndtere de forskellige forventede XML elementer i de korrekte blokke er pænere end try catch.

- Jeg er ikke tvivl om, at vi begge er 100% klar over hvornår man bør benytte en try catch, men der er åbenbart forskel på din og min programmeringsstil:), men det skal der også være plads til.

Jeg er 100% uenig omking det XML, og det jeg syntes det virker som om er at du ikke har forstået min situation i mit eksempel... for der er ikke noget "looperi"... dokumentet havde en forholdsvis fast struktur hvilket tilod at man gjorde det som jeg sagde... og det var en forudsætning... en såkald Precondition...

Men som svar på det sidste... "hvornår man bør benytte try catch"... der er ikke noget "nu bør man benytte try catch"... der er ingen regler for benyttelse af det... der er best practices... og de er milevidt forskellige...

Taget et eksempel fra en bog jeg har omkring Fault-Tolerant Systems

Der nævnes følgende måde fx som en fuldkommen ok måde at behandle et Out-of-the-Ordinary Event ved læsningen af en fil... observer:

try
{
  //Læsfra filen
}
catch (EndOfStreamException ex)
{
  //Afslut læsningen og luk (luk evt. i en finaly blok)
}

Men man kunne jo også have:

if(stream.Position < stream.Length)
{
  //Læs
}
else
{
  //Afslut
}

Begge ok måder at løse en problemstilling på, og man kan så med subjective holdninger foretrække den nederste... det er fair nok... men der er ikke noget galt i nogen af dem...

Evaluer også:
int i = 0;
while(true)
{
  try
  {
    myCollection[i++].DoSomething();
  }
  catch
  {
    braek;
  }
}

Skørt kode vil mange sige, og grimt kode tilmed (syns jeg selv)... men det er ikke forkert kode... og det er IMO en vigtig pointe...

"Men som svar på det sidste... "hvornår man bør benytte try catch"... der er ikke noget "nu bør man benytte try catch"... der er ingen regler for benyttelse af det... der er best practices... og de er milevidt forskellige"

det kommer så sandelig an på hvad du koder:)
I Java er du tvunget til, at håndtere exceptions  -  men ikke i C#

Hvis strukturen er fast og man ved alle elementer vil eksistere så behøver man heller ikke try catch for så ved man det ikke vil fejle.

men jeg tænker på xml du modtager fra en 3 part som gerne skulle holde sig til en bestemt struktur, men man ved aldrig hvad en 3 part kan finde på, at lave af ændringer:) (eller hvordan denne 3part håndtere fejl)

Jeg ville stadig benytte en switch til, at udlæse et XML document med en fast struktur og løkken er bare min måde, at løbe XML'en igennem og dermed slippe for .SelectSingleNode


egentlig så tror jeg ikke, at vi er uenige når det kommer til stykket - tror problemet lægger i hvordan vi prøver at forklare os overfor den anden:)

Bruger slet ikke SelectSingleNode nogen steder... bruger alm. []...

Nej, jeg kan ikke vide hvad 3. part kan finde på... MEN netop derfor har jeg min try catch... for hvis 3. part ikke anger fx baudrate... så kan jeg ikke bruge resten af parametrene til en hat... derfor bliver jeg nød til at lade hele den del af korthuset falde sammen... og så gøre opmærksom på at der er sket en fejl istedet, så 3. part kan udbedre det... det virker fint på den måde jeg nævner er er IMO noget både nemmere og pænere kode end hvis jeg skulle til at loope igen en række noder...

han må ordne noderne akurat som han vil inden for deres parent... men han må ikke undlade en... alle disse er valid med den måde jeg gør det på:

<PortSettings>
  <BaudRate>9600</BaudRate>
  <DataBits>8</DataBits>
  <Parity>None</Parity>
  <StopBits>1</StopBits>
  <FlowControl>None</FlowControl>
  <Encoding>i-ascii</Encoding>
</PortSettings>

eller

<PortSettings>
  <StopBits>1</StopBits>
  <FlowControl>None</FlowControl>
  <Encoding>i-ascii</Encoding>
  <BaudRate>9600</BaudRate>
  <DataBits>8</DataBits>
  <Parity>None</Parity>
</PortSettings>

Bare alle de nødvendige childs er der virker det fint. men mangler en skal hele Portsettings kastes ud, og den port kan ikke oprettes... dertil er der en masse andre ting som også falder sammen... men med så forskellige indstillinger der er på de porte der skulle logges fra, så er nogen som helst form for standardværdi umulig at smide ind på en manglende parameter... et loop vil intet gavn gøre mig...

Settings er assigned således:
try
{
  string port = set.Properties[ "name" ];

  SerialSettings comSettings = new SerialSettings();
  comSettings.BaudRate = SerialSettings.ParseBaudRate( set[ "PortSettings" ][ "BaudRate" ].Value );
  comSettings.DataBits = SerialSettings.ParseDataBits( set[ "PortSettings" ][ "DataBits" ].Value );
  comSettings.Handshake = SerialSettings.ParseHandshake( set[ "PortSettings" ][ "FlowControl" ].Value );
  comSettings.Parity = SerialSettings.ParseParity( set[ "PortSettings" ][ "Parity" ].Value );
  comSettings.StopBits = SerialSettings.ParseStopBits( set[ "PortSettings" ][ "StopBits" ].Value );

  Encoding encoding = ItalicASCIIEncoding.Parse( set[ "PortSettings" ][ "Encoding" ].Value );

  SLog.WriteEntry( LogEntryType.Load, "Loading character set {0}", encoding.EncodingName );

  ReportParser parser = new ReportParser();
  parser.SetPortlistener( port, comSettings, encoding );
}
catch (Exception ex)
{
  //Log and inform code....
}

Du er ikke tvunget til det i C#... men det syntes jeg ikke altid er nogen god ide, for det gør mange ikke gør det... dermed får man fejl... og til den her:

"Hvis strukturen er fast og man ved alle elementer vil eksistere så behøver man heller ikke try catch for så ved man det ikke vil fejle."

Lad mig reposte denne:

"Computer software is far more complex still, and with that complexity comes an increased propensity to failure. It is probably fair to say that there is not a single large piece of software or hardware today that is free of bugs."

Der er ALTID sandsynlighed for fejl, bugs osv... at tro meget andet er imo naivt... Vores hardware har en stor mængde fejl-tolerance indbygget... men det giver aldrig en 100% solid platform... så Datafejl i ram osv sker stadig... så hvis du arbejder (som mig) med yderst kritiske systemer er der ikke noget der heder "Jeg er sikker på det ikke fejler"... der er kun noget der heder "Jeg er sikker på det kan fejle" hvor usandsynligt det end er....

md_craig

hvis du ikke bruger SelectSingleNode men altid kan nøjes med []
så arbejder du også kun med simple XML documenter.
Jeg benytter ofte XPATH til, at komme ind til den XML blok der har interesse og ja så kan [] benyttes efterfølgende.

Det er en anden snak.

Dit eksempel bekræfter lidt tanken om simpel XML.
Du skal ikke tro, at alle arbejder med XML hvor det er vigtigt, at ALT er med.. det kan være ret så variabelt!
Det kan være helt bevidst fra 3 part at de i nogle situationer ikke sender 2 eller 3 noder med.

Derfor giver det ikke mening, at smide resten ud i sådan et tifælde og slet ikke mening, at det hele skal falde ned i en catch blok.

Til din repost kan jeg kun sige, at der på intet tidspunkt i det jeg har skrevet er blevet sagt, at min kode er "free og bugs".
Det eneste jeg siger er, at hvis man kan undgå en try catch blok så bør man også - det er min holdning til det.

Jeg ser ofte, at "try catch" bliver misbrugt i situationer hvor koden blot kunne være skrevet anderledes og det forbinder jeg lidt med en doven programmør.

Så er der kun en ting jeg kan sige... så har du jo ikke lyttet til mit eksempel fra starten... og når det er tilfælde er alt det her 100% spild af min tid...

Jeg har lagt problemstillingen ud... en Fastlagt, fastformateret XML indsillingsfil som der var lavet guidelines til... hvor advanceret kan den nu lige være?...

Nej sorry... når du prøver at rede situationen ved at drege den til nogen andet end de eksempler jeg bruger til at forklare at try catch kan have sine formål med XML... og at jeg samtidig siger følgende:

Citat:
Kommentar: md_craig
18/07-2007 09:51:53

"Var der derimod en "Normal tilstand" at der kunne mangle en eller flere parametre, så ville jeg naturligvis bruge if's istedet..."

....

Jamen så kan jeg jo tydelig vis ikke diskutere med dig... for det du siger her:

"Du skal ikke tro, at alle arbejder med XML hvor det er vigtigt, at ALT er med.. det kan være ret så variabelt!
Det kan være helt bevidst fra 3 part at de i nogle situationer ikke sender 2 eller 3 noder med."

Jamen så passer det på min situation hvor "manglende" noder er en NORMAL tilstand... og så gider jeg ikke det her mere... for så hører du jo ikke efter...