[VB.Net] Trage exception handling?

[RobIII]

Ik ben (eindelijk ) eens een beetje aan het spelen met VB.Net, en kom net iets vreemds tegen:

Visual Basic .NET:

    Public Sub Main()

        Dim intgetal1 As Decimal
        Dim intgetal2 As Decimal

        intgetal1 = 5
        intgetal2 = 0

        Try
            Console.WriteLine(Now & " Start try")
            Dim intgetal3 As Double = CType((intgetal1 / intgetal2), Double)
            Console.WriteLine(intgetal3)
        Catch ex As System.DivideByZeroException
            Console.WriteLine(Now & " Whoops! Division by zero!")
        Catch ex As Exception
            Console.WriteLine(Now & " " & ex.Message)
        Finally
            Console.WriteLine(Now & " Finally")
        End Try
        Console.WriteLine(Now & " Done")

        Console.ReadLine()
    End Sub

De output die ik nu in mijn console krijg is als volgt:



De oplettende lezer zal het opvallen dat er 2 sec. verschil zit tussen het try statement en het catch statement. Ik vraag me af waar die vertraging vandaan komt? Deze vertraging is goed merkbaar tijdens het runnen van de applicatie, maar ook in de debug-mode (met F8 er door heen stappen dus).

Ik heb het niet exact getimed, maar 2 seconden om een exception te vangen is wel erg veel toch?

Ik ben redelijk nieuw in .Net en ben me er na jaren van uitstel eindelijk in aan het verdiepen. "Vroegah", in de VB6 tijd , had ik geen last van dit soort rare vertragingen. Heb ik ergens een optie verkeerd staan of mis ik ergens iets? Is dit normaal?

[whoami]

Nee, want in VB6 had je geen exceptions.

Een exceptie gooien is zowiezo duur, maar 2 seconden is eigenlijk best lang. Duurt het ook nog zo lang als je de applicatie erna ook nog eens uitvoert?

[cvs79]

He je de applicatie gebuild als debug of als release??? Want bij release is zowieso een stuk sneller omdat de debug code er dan uit gelaten wordt door de compiler

[pjvandesande]

In VB6 had je geen exceptions zoals Whoami al zegt. Exception kunnen zeer waarde volle informatie vast houden.
Exceptions zijn langzaam. 2 sec vind ik erg lang. Maar dit kan ook 1.1 seconden zijn als het al bijna 2:09:09 was.

Meestal als je je app voor de 2e keer runt gaat het sneller. Denk er aan dat exceptions niet de lij-draad van je app moeten zijn. Dus controlleer ingetal2 zelf of deze niet 0 is, ik snap dat het hier om een voorbeeld gaat.

[gorgi_19]

questa schreef op 01 april 2004 @ 08:54:
In VB6 had je geen exceptions zoals Whoami al zegt. Exception kunnen zeer waarde volle informatie vast houden.
Exceptions zijn langzaam. 2 sec vind ik erg lang. Maar dit kan ook 1.1 seconden zijn als het al bijna 2:09:09 was.

Meestal als je je app voor de 2e keer runt gaat het sneller. Denk er aan dat exceptions niet de lij-draad van je app moeten zijn. Dus controlleer ingetal2 zelf of deze niet 0 is, ik snap dat het hier om een voorbeeld gaat.

Je moet Exceptions niet gebruiken als 'normale' code in plaats van bijvoorbeeld if statements
In dit geval is het een fatale uitzondering en dan is de applicatie afgelopen en kan je dus best een exception gebruiken.
Sowieso is 1.1 seconden voor een exception erg traag.

[Korben]

gorgi_19 schreef op 01 april 2004 @ 08:57:
[...]
Sowieso is 1.1 seconden voor een exception erg traag.

Mjah, maar als je naar je CPU usage kijkt, zul je zien dat je usage naar de 100% knalt, en dat is (my guess) omdat je debugger probeert te tracen waar in je code de exception wordt gethrowed.

[pjvandesande]

Een exception duurt bij mij soms ook wel wat langer. Als de application nog als DEBUG gecompiled is en Visual Studio, me debugger nog meekijkt.

Maar 1a2 seconden vind ik ook nog vrij lang. Zeker omdat deze exception niet diep genesteld zit in classes. Maar dat maakt kwa snelheid ook niet veel uit.

[RobIII]

Ik weet dat VB6 geen exceptions kent, ik bedoelde dat alleen maar ter illustratie...

Als ik de app een paar keer achter elkaar run, blijft de vertraging bestaan. Ik heb de applicatie nog niet gebuild als release, en dat zal ook wel beter worden dan, maar ik vroeg me gewoon af waarom het zo lang duurt?

Maar dan nog, regardless of het nu 1.9 of 2.03 seconden duurt, ik vind dit erg lang? Ik begrijp dat er bij een exception heel de stack wordt teruggetraced en de garbage collector waarschijnlijk ook meteen wat zooi opruimt, maar waarom zo lang?

Hebben jullie hier ook last van dan? Ik dacht (hoopte) eigenlijk dat het gewoon aan mijn systeem lag (alhoewel dat een PIV 2.8Ghz HT met 1Gb ram is op een ASUS P4P800).

Ik ben wel aardig thuis in programmeren an sich (zie profiel ), hoewel .Net nog redelijk nieuw is voor me, maar ik vond het dus gewoon vreemd dat er "ongeveer" 2 seconden nodig was om die exception te vangen.

En nee, ik probeer exceptions niet te gebruiken i.p.v. If-statements zoals gorgi_19 zegt, het was puur een "testje"...

[ Voor 5% gewijzigd door RobIII op 01-04-2004 12:57 ]

[farlane]

whoami schreef op 01 april 2004 @ 08:30:
Nee, want in VB6 had je geen exceptions.

Ik vind de error handling van VB6 toch wel behoorlijk op exceptions lijken, alhoewel minder uitgebreid.

[ Voor 5% gewijzigd door farlane op 01-04-2004 13:52 ]

[whoami]

farlane schreef op 01 april 2004 @ 13:52:
[...]


Ik vind de error handling van VB6 toch wel behoorlijk op exceptions lijken, alhoewel minder uitgebreid.

Heb je 'error bubling' in VB6 ? Kan je nagaan welk type fout er opgetreden is?

[gorgi_19]

whoami schreef op 01 april 2004 @ 13:53:
[...]



Heb je 'error bubling' in VB6 ? Kan je nagaan welk type fout er opgetreden is?

On Error Resume Next en dan de Error code uitlezen / vergelijken.

[whoami]

gorgi_19 schreef op 01 april 2004 @ 13:54:
[...]

On Error Resume Next en dan de Error code uitlezen / vergelijken.

Ik heb niet zo bijster veel ervaring in vb6, maar een dergelijke structuur/method is toch niet mogelijk in vb6?

code:

try
{
    SomeFunction();
}
catch( ApplicationException ex )
{
   MessageBox.Show("app exc: " + ex.Message);
}
catch( Exception ex )
{
    MessageBox.Show (ex.Message);
}

void SomeFunction()
{
    // bla
    if( bla )
    {
         throw new ApplicationException("Error occured in somefunction");
         // er wordt direct naar de juiste catch gesprongen
    }
}

Ik bedoel dus: als er een fout optreedt in VB6, dan kan je die exceptie toch niet afhandelen in de 'calling' functie, of wel?

[ Voor 9% gewijzigd door whoami op 01-04-2004 14:03 ]

[gorgi_19]

Eerder iets als:

VBScript:

Sub DoSafeDivide(x, y)
 
       On Error Resume Next

       z = x / y
       If Err.Number > 0 Then
              Response.Write("Division failed:  " & x & " / " & y & "<BR>")
              Response.Write("Error source: " & Err.Source & "<BR>")
              Response.Write("Error number: " & Err.Number & "<BR>")
              Response.Write("Error description: " & Err.Description & "<BR>")
              Err.Clear
       Else
              Response.Write("Division succeeded: " & x & " / " & y & " = " & z & "<BR>")
       End If
       On Error Goto 0
End Sub

[ Voor 48% gewijzigd door gorgi_19 op 01-04-2004 14:07 ]

[whoami]

Hmmm, jah, dat kan je imo toch niet echt 'gestructureerde exception handling' noemen hoor...

[gorgi_19]

whoami schreef op 01 april 2004 @ 14:08:
Hmmm, jah, dat kan je imo toch niet echt 'gestructureerde exception handling' noemen hoor...

't is wat lastiger met al die verschillende error numbers, ja.. Ook On Error Goto 0 is niet verplicht, waardoor je binnen no time een enorm try block creeert.

[ Voor 19% gewijzigd door gorgi_19 op 01-04-2004 14:08 ]

[farlane]

whoami schreef op 01 april 2004 @ 14:02:
Ik heb niet zo bijster veel ervaring in vb6, maar een dergelijke structuur/method is toch niet mogelijk in vb6?

Niet zo uitgebreid, en zeker niet structured maar bij benadering wel:

Visual Basic:

Public Sub test()

  On Error GoTo ErrorHandler
  
  Call SomeFunction

  Exit Sub
  
ErrorHandler:

  Dim E As Long: E = Err.Number
  Select Case E
  
    Case ERR_APPLICATION:
      Call MsgBox("app exc: " + Err.Description)
    Case ERR_EXCEPTION:
      Call MsgBox(Err.Description)
  End Select
  
  Resume Next
  
End Sub


Function SomeFunction() As Variant
  If bla Then
    Call Err.Raise(ERR_APPLICATION, , "Error occured in somefunction")
    ' Er wordt niet direct naar de goede catch gesprongen
  End If
End Function

Ik bedoel dus: als er een fout optreedt in VB6, dan kan je die exceptie toch niet afhandelen in de 'calling' functie, of wel?

Dat dan weer wel, VB6 kent een vergelijkbaar stack unwind mechanisme als C++.

[ Voor 14% gewijzigd door farlane op 01-04-2004 14:39 ]

[curry684]

gorgi_19 schreef op 01 april 2004 @ 13:54:
[...]

On Error Resume Next

offtopic:
Niet vloeken in Programming & Webscripting

[gorgi_19]

curry684 schreef op 01 april 2004 @ 15:23:
[...]

offtopic:
Niet vloeken in Programming & Webscripting

D'r is niets mis met deze methodiek, mits goed gebruikt.

[ZaZ]

offtopic:
oh leuk zullen we dan er ook nog maar een discussie tegenaan gaan gooien of Goto eigenlijk per definitie fout is?

[curry684]

gorgi_19 schreef op 01 april 2004 @ 15:24:
[...]

D'r is niets mis met deze methodiek, mits goed gebruikt.

In de context 'on error resume next' vind ik deze opmerking gelijk staan aan zeggen dat alle kleuters vuurwapens moet kunnen dragen, mits goed gebruikt

[gorgi_19]

curry684 schreef op 01 april 2004 @ 15:35:
In de context 'on error resume next' vind ik deze opmerking gelijk staan aan zeggen dat alle kleuters vuurwapens moet kunnen dragen, mits goed gebruikt

't is hetzelfde als

Visual Basic .NET:

Try
   ' code
Catch
End Try

Zelfde principe. VB6 heeft geen betere mogelijkheden van error handling. Als je try-catch statements misbruikt, krijg je even ranzige constructies.

[ Voor 19% gewijzigd door gorgi_19 op 01-04-2004 15:38 ]

[farlane]

On Error Resume Next is een veroorzaker van de meest ranzige bugs die je kunt bedenken, en waarvan je maar moeilijk nog een oorzaak kunt achterhalen. ( Op z'n minst moet er een logmelding van komen dat er een fout is geweest )

In hetzelfde straatje als het niet gebruiken van Option Explicit, en modules vol met globale variabelen.

[MSalters]

Zou het kunnen dat de exception code nog niet geladen/gecompiled is? Met .Net en de CLR wordt je code on-demand gecompileerd, en ik geloof direct dat als je je hele exception-handler spul opeens moet laden en compileren, dat dat even duurt. De meeste programma's gooien geen exceptions in normaal gebruik (exception betekent uitzondering), dus dat is een valide optimalisatie.

[RobIII]

MSalters schreef op 01 april 2004 @ 19:35:
Zou het kunnen dat de exception code nog niet geladen/gecompiled is? Met .Net en de CLR wordt je code on-demand gecompileerd, en ik geloof direct dat als je je hele exception-handler spul opeens moet laden en compileren, dat dat even duurt. De meeste programma's gooien geen exceptions in normaal gebruik (exception betekent uitzondering), dus dat is een valide optimalisatie.

Ga ik effe testen Moment a.u.b.

And we have a winner! Zelfde code 2x achter mekaar:

1e keer: 2 a 3 sec vertraging
2e keer knalt 'ie er zo door heen!

Ik denk dus dat je correct bent! Weer iets geleerd

[ Voor 16% gewijzigd door RobIII op 01-04-2004 19:41 ]