[c#] error-handling discussie *

[Verwijderd]

Het zal wel een heeele stomme vraag zijn maar eeuh, ik kom er niet uit dus....
Hoe maak ik in vredesnaam een int van een string.
Ik heb van alles geprobeerd; casten werkt niet, er bestaat ook niet zoiets als .toInt
Damn ! Iemand een idee ?

[Verwijderd]

code:

  int i;
  try 
  {
     i=int.Parse(str);
  }
  catch (Exception e)
  {
     //Whoops error tijdens conversie, 
  }

zoiets?

[whoami]

Bekijk eens de Convert class, die heeft een aantal static functions voor conversies, zoals waarschijlijk ook ToString.

code:

Convert.ToString(bla);

Maar, in C# is alles een object (ook de primitieven, zoals int). Objecten hebben member functies, dus ook een int.
de gemakkelijkste en meest leesbare manier is dan ook deze:

code:

int i = 5;
string str;
str = i.ToString();

of

code:

Console.WriteLine(5.ToString());

[Orphix]

Op zondag 26 mei 2002 20:55 schreef whoami hoe je van int naar string kan converteren

Tja alleen dan de andere kant om

[getty]

Convert.ToInt32(str);

of

(int)str;

[whoami]

Tja, te snel gelezen ofzo.

Maar ik heb iets gezegd van die Convert class, en zoals getty reeds zei heb je daar ook een static function ToInt32()

[mulder]

Op zondag 26 mei 2002 14:19 schreef Yarvieh het volgende:

code:

  int i;
  try 
  {
     i=int.Parse(str);
  }
  catch (Exception e)
  {
     //Whoops error tijdens conversie, 
  }

zoiets?

Beetje vies, is er geen IsNumeric of iets dergelijks?

[whoami]

Ik vind een exception wel mooier dan bv een:

code:

if (strGetal.IsNumeric() == true)
{
  iGetal = Convert.ToInt32(strGetal);
}

Met een exception vang je gewoon uitzonderlijke situaties op, en dit is het geval als je een string (waarvan je verwacht dat er een 'getal' inzit) wilt casten naar een int.

[mulder]

Hmm, tja ik heb doordat in met VB ben begonnen met programmeren eigenlijk een hekel aan error handlers. Hoewel zelf errors raisen wel weer mooi is. Hmmm. /me Facundo snapt zichzelf even niet.

[whoami]

[visionair-mode]
* whoami ziet hier een discussie verschijnen over foutafhandeling...
[/visionair-mode]

Op zondag 26 mei 2002 22:40 schreef Don Facundo het volgende:
Hmm, tja ik heb doordat in met VB ben begonnen met programmeren eigenlijk een hekel aan error handlers. Hoewel zelf errors raisen wel weer mooi is.

Ik denk niet dat je error-handlers in VB kunt vergelijken met de mooie exceptions zoals die in C++, C#/VB.NET (.NET dus), Delphi, etc. geimplementeerd zijn.

Exceptions zijn function-wide (of hoe moet ik het uitleggen? ). VB error handlers vind ik totaal niet gestructureerd. Dit is toch de VB-way :

code:

if fout then
 goto error_handler;
else
 goto einde_func
end if

error_handler:

einde_func:

? Bah.

[mulder]

Yup, gelukkig voor de VB.Net programmeurs is dat nu veranderd. Toch lijkt het me in dit geval netter om een error te voorkomen. Tja. Is maar een gevoel.

[whoami]

Maar, als je zo pro-actief werkt, dan heb je wel een extra if. (Maar misschien dat dit achter de schermen ook gebeurd voor er eventueel een exception gethrowed wordt).

[Verwijderd]

ahem, als topicstarter hoor je dan ook zelf ff op te letten of er wordt gereageerd...
Thanx voor de hints, ik heb uiteindelijk 'convert' gebruikt;

code:

strInPutIP = Console.ReadLine();
strInPutIParray = strInPutIP.Split('.');
foreach (int intOctect in intOctetArray)
    {
        intOctetArray[intOctect] = Convert.ToInt16(strInPutIParray[intOctect]);
    }

Het leek me al vreselijk sterk dat er niet zoiets bestond.
Werkt als de brandweer

[Verwijderd]

Foutje in de foreach teller;

code:

foreach (int intOctect in intOctetArray)
    {
    intOctetArray[intOctect-1] = Convert.ToInt64(strInPutIParray[intOctect-1]);
    }

[whoami]

Op maandag 27 mei 2002 14:20 schreef Segunda@Tweakers het volgende:

Foutje in de foreach teller;

code:

foreach (int intOctect in intOctetArray)
    {
    intOctetArray[intOctect-1] = Convert.ToInt64(strInPutIParray[intOctect-1]);
    }

Ehm, ja ?

[whoami]

Op zondag 26 mei 2002 22:42 schreef whoami het volgende:
[visionair-mode]
* whoami ziet hier een discussie verschijnen over foutafhandeling...
[/visionair-mode]

Die komt er dus blijkbaar toch niet. Misschien dat ik nog eens moet nadenken over mijn talenten als visionair...

[Verwijderd]

Op maandag 27 mei 2002 21:06 schreef whoami het volgende:
Misschien dat ik nog eens moet nadenken over mijn talenten als visionair...

Al 'n cup'a'soupie genomen ?

[whoami]

Op maandag 27 mei 2002 21:09 schreef Yarvieh het volgende:

[..]

Al 'n cup'a'soupie genomen ?

c'est quoi ça? Minute-soup?

[Verwijderd]

Op maandag 27 mei 2002 21:12 schreef whoami het volgende:

[..]

c'est quoi ça? Minute-soup?

http://www.wijwillencupasoup.nl/

[mulder]

Nou kan wel even iets proberen:
wat is mooier:

code:

try
  if Not IsNumeric(testValue)
    Err.Raise "Not a number"
  i = testValue
  ...
except
  MessageDlg(Err.Message)

of:

code:

try
  i = ToInt32(testValue)
  ...
except
  MessageDlg(Err.Message)

Ik kan me nl voorstellen dat de 2e optie tot ongewenste/onvoorspelbare resultaten/error messages kan leiden.

Zie ook de bv de conversie in dit: [topic=470846] topic

[whoami]

Waarom zet je dit statement in uw eerste voorbeeld nog binnen een try-block als je een eventuele fout toch al via die IsNumeric wilt opvangen? (Ervan uitgaande dat er geen andere statements binnen het try-block zitten die tot exceptions kunnen leiden).

Ik vind een try/except oplossing veel leesbaarder dan een pro-actieve if-oplossing. En het zal even veilig zijn mits je de nodige catch blokken specifieert. En volgens mij is het ook veel onderhoudbaarder cq aanpasbaar.

[mulder]

Op maandag 27 mei 2002 21:38 schreef whoami het volgende:
...Ervan uitgaande dat er geen andere statements binnen het try-block zitten die tot exceptions kunnen leiden..

Daar ga ik juist wel van uit. Ik vind dat het tot een mooiere flow leidt. Maar ja, ik heb er niet voor geleerd, het is meer een gevoel, zoals ik al eerder zei. Niet dat ik gevoelens voor m'n code heb

[whoami]

Tja, een mooiere flow. Dat vind ik nu net niet.

En stel dat die Convert.ToInt32 functie bijvoorbeeld zelf ook checked of een string wel naar een int32 te converteren is, zodat er eventueel een exception kan gegooid worden, dan heeft jouw code wel 2x dezelfde controle gedaan.

_{Gevoelens voor m'n code.... ok, I admit}

[whoami]

* whoami forceert een discussie over error-handling door een te vroege, en dus eigenlijk illegale kick-actie en een verandering van topic-titel aan te vragen.

[Verwijderd]

Gebruik eerst System.Double.TryParse(). Die geeft true/false terug of een conversie kan of niet. Indien true, dan convert je, anders doe je niets, (of gooi je een error, whatever).

[Verwijderd]

Op zondag 26 mei 2002 22:42 schreef whoami het volgende:
Exceptions zijn function-wide (of hoe moet ik het uitleggen? ). VB error handlers vind ik totaal niet gestructureerd. Dit is toch de VB-way :

code:

if fout then
 goto error_handler;
else
 goto einde_func
end if
error_handler:
einde_func:

? Bah.

Als je ergens over gaat braken, zorg dan dat je er iets van weet. Staat zo lullig nu.

VB6 heeft on error goto handler. Is soms erg handig, soms ook niet.

voorbeeld:

code:

private sub foo()
on error goto handler
      'statements
      exit sub

handler:
      ' handle error
end sub

Dit is handig wanneer je bv 5 API calls achter elkaar wilt doen en een error bij elke call niet terminaal is. Met try/catch kom je er dan niet, of je moet om elke call een try/catch block plakken. In VB6's methode gebruikte je bovenstaand schema en deed je 'resume next' na het afhandelen van de error.

Niet dat dit soort code vaak voor komt, maar het kan een probleem zijn, die try/catch.

Verder gebruiken veel mensen try/catch blokken verkeerd: men initialiseert bv variabelen in de try clause.

[CyberSnooP]

De vraag is dus of je:
• Uitzonderingen actief zelf test (in dit geval met een IsNumeric() functie) alvorens een actie (een conversie) uit te voeren waarbij deze uitzonderingen kunnen optreden.
• Je de conversie zondermeer poogt uit te voeren en de eventuele uitzondering afhandelt als die op mocht treden.

Ik weet niet wat de beste keuze is in dit geval.
Voor het eerste geval valt te beargumenteren dat je code uiteindelijk tweemaal dezelfde checks uitvoert.
Voor het tweede geval is het argument dat je een uitzondering laat optreden.

Eventuele leesbaarheid vind ik maar ten dele een argument.

Is de 2e keuze werkelijk efficienter dan de eerste (voorkom je dubbele checks?). Zijn er nadelen of risico's aan het laten optreden van een exception?

[whoami]

Op dinsdag 28 mei 2002 21:09 schreef Otis het volgende:


Als je ergens over gaat braken, zorg dan dat je er iets van weet. Staat zo lullig nu.

Ik heb niet gezegd dat ik wat van VB ken, en het was ook niet mijn bedoeling om de juiste syntax van die error-handling bij VB neer te zetten.
Het ging mij gewoon om het principe. De leesbaarheid laat de wensen over, en die manier van error-handling schiet op veel punten te kort met de exceptions manier in .NET, C++, Java, etc.

[mulder]

Op dinsdag 28 mei 2002 21:09 schreef Otis het volgende:

Dit is handig wanneer je bv 5 API calls achter elkaar wilt doen en een error bij elke call niet terminaal is. Met try/catch kom je er dan niet, of je moet om elke call een try/catch block plakken. In VB6's methode gebruikte je bovenstaand schema en deed je 'resume next' na het afhandelen van de error.

Dat is dus behoorlijk smerig. Je wilt dus vanaf de 'veroorzaker' naar errorhandler springen (melding geven) en dan weer terug naar de code? Spagetticode heet dat. Een error betekent dat er iets fout gaat, en dus ga je niet verder volgens de normale route.

[Verwijderd]

Op dinsdag 28 mei 2002 21:05 schreef Otis het volgende:
Gebruik eerst System.Double.TryParse(). Die geeft true/false terug of een conversie kan of niet. Indien true, dan convert je, anders doe je niets, (of gooi je een error, whatever).

Eigenlijk is dit natuurlijk ook wel een beetje gek...TryParse zal dan waarschijnlijk geimplementeerd zijn als

code:

try
  DoParse(..)
  return true;
catch
  return false;

oid. Ik bedoel, om te kijken of je kan parsen, moet je parsen toch...

[Orphix]

Ik denk dat het in dit geval er van afhangt hoe je er tegenaan kijkt.
Stel je bouwt een internet browser, nu kan een nummer in een attribuut niet goed geparsed worden. Who cares, gewoon default value zetten en doorgaan met renderen.
Maar stel dat je gegevens opvraagt en wilt opslaan in een database. Je zet deze rij van acties (het converteren en opslaan in een database).
Je wilt geen foute informatie in de database hebben, dus moet zodra een fout optreedt direct worden gestopt met de operatie.

Imo ligt het er dus aan of een fout terminaal moet zijn of niet.

[Orphix]

Op dinsdag 28 mei 2002 22:08 schreef hondass50 het volgende:
Eigenlijk is dit natuurlijk ook wel een beetje gek...TryParse zal dan waarschijnlijk geimplementeerd zijn als

code:

try
  DoParse(..)
  return true;
catch
  return false;

oid. Ik bedoel, om te kijken of je kan parsen, moet je parsen toch...

Ik zou daar niet zo zeker van willen zijn. DoParse gebruikt intern natuurlijk een bepaalde check om te kijken of het een nummer is. Als TryParse deze check ook direct doet kan het daarmee eventuele overhead van excepties teniet doen.

[Verwijderd]

Op dinsdag 28 mei 2002 21:51 schreef Don Facundo het volgende:
[..]
Dat is dus behoorlijk smerig. Je wilt dus vanaf de 'veroorzaker' naar errorhandler springen (melding geven) en dan weer terug naar de code? Spagetticode heet dat. Een error betekent dat er iets fout gaat, en dus ga je niet verder volgens de normale route.

Waarom is dat smerig in alle gevallen? Ik zeg toch: wanneer de error niet terminaal is voor je programma, dus wanneer je dan die call skipt, maar de rest moet doorgaan. Dit was een vraag in de C# newsgroup van MS van iemand die dit moest bouwen en die had geen andere keus dan om elke call een try/catch blok te plaatsen.

Je weet overigens ook niet wat spagetticode inhoudt, want dit is het zeker niet. Als ik een error van een api-call in een file wil loggen en daarna door wil gaan met de volgende api-call, dan kan ik dat gemakkelijk in VB, in C# e.d. niet. Wanneer er een fout optreedt is dat niet altijd 'the end has come'-fout, maar soms gewoon 'ok, bump in the road, move along!'

Het is JUIST dat besef dat er verschil is tussen die uitersten, wat doorslaggevend is voor het bouwen van goede error-handling. Jij kapt dus je programma af na iedere simpele error? "Save file" -> Error, save failed, file bestaat al -> exit. ? Ik hoop het niet.

[Verwijderd]

Op dinsdag 28 mei 2002 22:08 schreef hondass50 het volgende:
[..]
Eigenlijk is dit natuurlijk ook wel een beetje gek...TryParse zal dan waarschijnlijk geimplementeerd zijn als

code:

try
  DoParse(..)
  return true;
catch
  return false;

oid. Ik bedoel, om te kijken of je kan parsen, moet je parsen toch...

Je kijkt dan even in de source van Rotor en ziet:

code:

      /// <include file='doc\Double.uex' path='docs/doc[@for="Double.TryParse"]/*' />
      public static bool TryParse(String s, NumberStyles style, IFormatProvider provider, out double result) {
        NumberFormatInfo info = NumberFormatInfo.GetInstance(provider);
        if (s == null || info == null) {
            result = 0;
            return false;
        }
        bool success = Number.TryParseDouble(s, style, info, out result);
        if (!success) {
            String sTrim = s.Trim();
            if (sTrim.Equals(info.PositiveInfinitySymbol)) {
              result = PositiveInfinity;
            } else if (sTrim.Equals(info.NegativeInfinitySymbol)) {
              result = NegativeInfinity;
            } else if (sTrim.Equals(info.NaNSymbol)) {
              result = NaN;
            } else
              return false; // We really failed
        }
        return true;
      }

ietsiepietsie anders

[marcusk]

Otis: Als ik een error van een api-call in een file wil loggen en daarna door wil gaan met de volgende api-call, dan kan ik dat gemakkelijk in VB, in C# e.d. niet.

Zoiets bedoel je: ?

code:

Private Sub Blaat()
    On Error Goto Handler

    ApiCall1 ...
    ApiCall2 ...
    ApiCall3 ...

    Exit Sub

Handler:
    WriteLog "Er is iets fout gegaan, maar ik weet niet " +  
         "precies in welke functie of wat er precies mis is. Sorry."
    Resume Next
End Sub

Dan vind ik de C# manier met excepties toch handiger

[Verwijderd]

marcusk: precies

Voor het meeste gebeuren heb je dit niet echt nodig, maar je kunt in de situatie komen.

Op zich heeft try/catch/finally wel veel voordelen tov de 'on error goto hell' VB solution, het dwingt je meer tot het opstellen van semi-atomaire logische blokken ipv 1 blok waar je met de ogen dicht en op goed geluk doorheen ragt .

Ach ja Nothin's perfect.

/me , die er vandaag achter kwam dat VB.NET geen operator overloading heeft, en dus geen gebruik kan maken van handige implicit cast operators in de .NET api classes. AAAARG

[Verwijderd]

Op woensdag 29 mei 2002 21:03 schreef Otis het volgende:Op zich heeft try/catch/finally wel veel voordelen tov de 'on error goto hell' VB solution, het dwingt je meer tot het opstellen van semi-atomaire logische blokken ipv 1 blok waar je met de ogen dicht en op goed geluk doorheen ragt .

Ach ja Nothin's perfect.

Precies. Ik vind dat beide manieren zo z'n voordelen hebben en vind het aan een kant jammer dat C# niet beide manieren ondersteunen.
De 'on error goto hell' is handig voor in de UI. Dan boeit het niet zozeer wát er fout ging (dat wordt toch wel gelogd door lagen daaronder), zolang je maar zeker weet dat je programma nooit met zo'n mooie .Net uncaught exception aankomt... want dan sta je mooi voor lul.
De try-catch is veel mooier als je weet dat bepaalde dingen fout kunnen gaan, en specifiek die fout kan afvangen...

Maar goed, als je 'on error ...' toestaat zullen er heel veel luie programmeurs zijn die niks meer catchen

[CubicQ]

oh, maar ook in de C# manier is ranzig programmeren niet zo moeilijk natuurlijk. Gewoon alles in een groot try block zetten en dan onderaan een catch(Exception e) {}

[mbravenboer]

CubicQ: oh, maar ook in de C# manier is ranzig programmeren niet zo moeilijk natuurlijk. Gewoon alles in een groot try block zetten en dan onderaan een catch(Exception e) {}

Exact: het leuke is dat je dat in C# gewoon alleen in de main kan zetten. Ben je overal van je exceptions af . In Java moet je dan nog overal 'throws' achter de methoden zetten .