[alg] Slechtste programmeervoorbeelden deel 4

[Standeman]

Wij hebben hier een aantal mooie van deze:

code:

try {
  //doe iets
}
catch (Exception x)
{
}

Wel mijn lieftallige collega geinstrueerd dit niet meer te doen en gelijk maar de reden van exception handling uitgelegd.
Als ik 'm nog ergens zie opduiken in gewijzigde sourcefile, smul ik de volgende dag taart!

[Verwijderd]

Standeman schreef op woensdag 06 mei 2009 @ 17:38:
Wij hebben hier een aantal mooie van deze:

code:

try {
  //doe iets
}
catch (Exception x)
{
}

Wel mijn lieftallige collega geinstrueerd dit niet meer te doen en gelijk maar de reden van exception handling uitgelegd.
Als ik 'm nog ergens zie opduiken in gewijzigde sourcefile, smul ik de volgende dag taart!

Bij bepaalde omstandigheden kan het wel makkelijk zijn om een try te doen met een lege catch
bv met het verwerken van communicatie welke niet altijd goed gaat ivm storing. en dan wil je de gebruiker niet lastig vallen omdat de volgende brok communicatie wel weer goed gaat.

dus ik vind een try met een lege catch niet perse fout

[ Voor 7% gewijzigd door Verwijderd op 06-05-2009 23:08 ]

[.oisyn]

Er is een verschil tussen een specifieke exception opeten en alle exceptions opeten.

[Nick_S]

Verwijderd schreef op woensdag 06 mei 2009 @ 23:05:
[...]


Bij bepaalde omstandigheden kan het wel makkelijk zijn om een try te doen met een lege catch
bv met het verwerken van communicatie welke niet altijd goed gaat ivm storing. en dan wil je de gebruiker niet lastig vallen omdat de volgende brok communicatie wel weer goed gaat.

dus ik vind een try met een lege catch niet perse fout

Doe dan nog minstens een logging wegschrijven, zodat als je deze code aan het testen bent het ook op gaat vallen als het wel erg vaak gebeurt. Lege catch clausules is not done!

[boe2]

Standeman schreef op woensdag 06 mei 2009 @ 17:38:
Wij hebben hier een aantal mooie van deze:

code:

try {
  //doe iets
}
catch (Exception x)
{
}

Wel mijn lieftallige collega geinstrueerd dit niet meer te doen en gelijk maar de reden van exception handling uitgelegd.
Als ik 'm nog ergens zie opduiken in gewijzigde sourcefile, smul ik de volgende dag taart!

Ik gebruik het soms ook hoor, er zijn genoeg situaties waar het kan gebeuren.

Bijvoorbeeld, ik heb een tooltje waarmee ik kan kijken of servers online zijn of niet. Iedere server kan ik in een apart venster openklikken. Ieder venster heeft een timer met backgroundworker waaronder deze code zit:

C#:

try
{
     PingReply pingReply = networkManager.Ping(server.ip);
     Invoke(new Changed(OnChange), pingReply);
}
catch (Exception)
{
}

Nu kan het gebeuren dat een antwoord op de ping lange tijd op zich laat wachten en dat je als gebruiker ondertussen het venster sluit. De Invoke die erachter komt zal dan een exception throwen. Aangezien er echter helemaal niets meer moet gebeuren (toch niets wat de GC niet zelf kan) slok ik gewoon de exception op.

Een bizarre die ik wel een tijdje geleden gezien heb:

C#:

catch(Exception ex)
{
   throw new Exception(ex.Message)
}

[ Voor 8% gewijzigd door boe2 op 07-05-2009 01:29 ]

[Standeman]

Tja, misschien in een aantal specifieke gevallen, maar niet als je SQL statements aan het afschieten bent

Zowiezo, als ik ergens een lege catch zie, is er 99 van 100 keer wat vergeten.

[ Voor 27% gewijzigd door Standeman op 07-05-2009 08:34 ]

[Sebazzz]

Daarvoor hebben ze throw uitgevonden op deze manier:

C#:

try {
     int y = 5 / 0;
} catch ( Exception ex ) {
     throw; // zelfde object, en stacktrace verschuift niet
}

Boeboe schreef op donderdag 07 mei 2009 @ 01:21:
[...]

Ik gebruik het soms ook hoor, er zijn genoeg situaties waar het kan gebeuren.

Mag je deze methode ook gebruiken in de volgende situatie: Je hebt een methode dat leest van een bestand en iets doet en dan wegschrijft naar een ander bestand, nu is het mogelijk dat door een oorzaak één van deze stappen (lezen, processen, wegschrijven) fout gaat en een exception opgooit, want je programma werkt bijvoorbeeld in een instabiele netwerkomgeving. Als je in de methode de exception hebt opgevangen, en eventuele eventhandlers hebt aangeroepen en gelogt hebt en uit de methode wilt stappen, wil je wel zo veel mogelijk resources opruimen om te voorkomen dat er bijvoorbeeld een filelock blijft staan totdat je programma gesloten is. Maar ook het sluiten van object kan problemen opleveren (Exceptions). Vangen met lege try catch of niet?

[YopY]

Een bizarre die ik wel een tijdje geleden gezien heb:

C#:

catch(Exception ex)
{
   throw new Exception(ex.Message)
}

Is niet bizar, maar geeft wel aan dat wie dat ook geschreven heeft eigelijk geen verstand heeft van exceptions. Ook aangezien de hele stacktrace hiermee verdwijnt.

Ik verdenk dat het CMS waar ik nu mee werk ook een paar van dit soort praktijken heeft, . Als er een exception in een .jsp voorkomt laat 'ie tenminste de stacktrace niet zien, zodat je alleen weet 'ja, d'r is iets mis in je jsp', terwijl het probleem veel dieper kan liggen.

Sebazzz schreef op donderdag 07 mei 2009 @ 08:35:
Daarvoor hebben ze throw uitgevonden op deze manier:

C#:

try {
     int y = 5 / 0;
} catch ( Exception ex ) {
     throw; // zelfde object, en stacktrace verschuift niet
}

Mja, dan heb ik liever Java, die de exception 'naar omhoog' gooit ipv dat je dat handmatig moet doen. Het nadeel daaraan is dat je soms nogal lange method signatures krijgt, maar ja, veel zaken zijn lang bij Java. Is niet negatief per sé overigens.

[ Voor 35% gewijzigd door YopY op 07-05-2009 09:20 ]

[Haan]

Als het over exceptions gaat heb ik ook nog wel een leuke. Onderstaande code heeft me laatst een aantal uur gekost voor ik het probleem boven water had..

C#:

public bool CreateFolder(string folderUrl)
{
     string folderpath = GetFolderPath(folderUrl);
     try
      {
           WebRequest request = WebRequest.Create(folderpath);                
           request.Credentials = CredentialCache.DefaultCredentials;
           request.Method = "MKCOL";
           WebResponse response = request.GetResponse();
           response.Close();
           return true;
       }
       catch (WebException)
       {
            return false;
       }
}

Dat deze vieze methode überhaupt nodig is, is te danken aan het feit dat het MS SharePoint team blijkbaar is vergeten om een methode te schrijven die kan checken of een map in een document library al bestaat. Daarom moet je dus proberen om een map aan te maken, en als dat mislukt kan je er vanuit gaan dat hij dus al bestond

So far so good, methode werkt goed op testserver waar webserver, database, SharePoint e.d. allemaal op draait. Dan even overzetten naar productieomgeving en daar werkt het gewoon niet.. Uiteindelijk bleken de default credentials niet te werken omdat de SharePoint server op een andere machine draait, en kreeg je wel een WebException, maar dan eentje met 'status 401: unauthorized', die dus netjes werd weggeveegd in de code

[HawVer]

Als je dan een exceptie op een hoog niveau wil catchen is het altijd nog beter om een SystemException te catchen dan op Exception

[BM]

Sebazzz schreef op donderdag 07 mei 2009 @ 08:35:
Daarvoor hebben ze throw uitgevonden op deze manier:

C#:

try {
     int y = 5 / 0;
} catch ( Exception ex ) {
     throw; // zelfde object, en stacktrace verschuift niet
}

Puur uit interesse, maar is het bovenstaande statement niet exact gelijk aan

C#:

int y = 5/0;

Dus zonder try/catch whatever?

(Neem aan dat er hier normaal logging bij staat, en dat exception daarna pas doorgegooit word ofzo)

[Janoz]

Boeboe schreef op donderdag 07 mei 2009 @ 01:21:

C#:

try
{
     PingReply pingReply = networkManager.Ping(server.ip);
     Invoke(new Changed(OnChange), pingReply);
}
catch (Exception)
{
}

Zelfs in dat geval zou ik er minimaal een LOG.trace() of LOG.info() in de catch zetten.

Een bizarre die ik wel een tijdje geleden gezien heb:

C#:

catch(Exception ex)
{
   throw new Exception(ex.Message)
}

Ja, want die stacktraces laten toch alleen maar de logfiles vollopen

Maar een vergelijkbare constructie gebruik ik zelf wel vaker, maar dan in iets andere vorm:

Java:

try {
  //wat sql code
} catch (SQLException sqle) {
  throw new ServiceException("Duidelijke omschrijving..",sqle);
}

Op deze manier scherm je de daadwerkelijke implementatie (in dit geval SQL) af van de bovenliggende lagen en heb je in die lagen geen afhankelijkheid meer naar sql.

[MTWZZ]

Maar je geeft vervolgens wel de SqlException mee als argument aan ServiceException....

[CodeCaster]

In een ander topic wordt naar deze video gelinkt. Wat schrijft de auteur?

PHP:

<?php

class dog {
  function eat_snake() {
    echo "The dog ate the snake!";
  }
}

class snake {
  function eat_bugs() {
    echo "He eats bugs.";
    
    $dog = new dog();
    $dog->eat_snake();
  }
}

$my_snake = new snake();
$my_snake->eat_bugs();

?>

Heb je daar een tutorial van vijf minuten voor nodig

[Haan]

Daarbij is het ook nog eens volkomen onlogisch om in die eat_bugs() functie een hond object te maken en daarop de eat_snake() functie aan te roepen

[Sebazzz]

BM schreef op donderdag 07 mei 2009 @ 09:45:
[...]

Puur uit interesse, maar is het bovenstaande statement niet exact gelijk aan

C#:

int y = 5/0;

Uiteraard is die ene regel gewoon wat voorbeeld code. Er had net zo goed en één of andere interessant statement kunnen staan.

[Janoz]

MTWZZ schreef op donderdag 07 mei 2009 @ 09:50:
Maar je geeft vervolgens wel de SqlException mee als argument aan ServiceException....

Uiteraard, als cause. Komt keurig terug in de uiteindelijke stacktrace, mocht je die willen ergens in de bovenliggende laag. Het verschil is dat de bovenliggende laag enkel van de ServiceException af hoeft te weten. Dat de cause een SQLException, een IOException (filesystem) of een AxisException (webservice) is maakt voor de bovenliggende lagen geen fluit uit.

[Janoz]

Sebazzz schreef op donderdag 07 mei 2009 @ 10:32:
[...]

Uiteraard is die ene regel gewoon wat voorbeeld code. Er had net zo goed en één of andere interessant statement kunnen staan.

Dab blijft de vraag staan. Wat is het verschil tussen

code:

try {
     //één of andere interessant statement 
} catch ( Exception ex ) {
     throw; // zelfde object, en stacktrace verschuift niet
}

en

code:

//één of andere interessant statement

Volgens mij namelijk helemaal niks, tenzij je, zoals BM aangaf, in de clause extra log info aan het afdrukken bent.

[Haan]

Sebazzz schreef op donderdag 07 mei 2009 @ 10:32:
[...]

Uiteraard is die ene regel gewoon wat voorbeeld code. Er had net zo goed en één of andere interessant statement kunnen staan.

Daar ging het denk ik niet om, maar om het feit dat

C#:

try
{
//doe iets
}
catch (Exception)
{
    throw;
}

gewoon op hetzelfde neerkomt als helemaal geen try/catch blok gebruiken

edit:
en te laat alweer

[ Voor 3% gewijzigd door Haan op 07-05-2009 10:43 ]

[Verwijderd]

Janoz schreef op donderdag 07 mei 2009 @ 10:38:
[...]


Dab blijft de vraag staan. Wat is het verschil tussen

code:

try {
     //één of andere interessant statement 
} catch ( Exception ex ) {
     throw; // zelfde object, en stacktrace verschuift niet
}

en

code:

//één of andere interessant statement

Volgens mij namelijk helemaal niks, tenzij je, zoals BM aangaf, in de clause extra log info aan het afdrukken bent.

Het verschil is dat je met de eerste code dan lokaal de checked exceptions (in java bijvoorbeeld) hebt afgehandeld.
Maar eigenlijk verschuif je het probleem daarmee, ergens moet je idd iets doen met die exception .

[Woy]

Verwijderd schreef op donderdag 07 mei 2009 @ 11:00:
[...]

Het verschil is dat je met de eerste code dan lokaal de checked exceptions (in java bijvoorbeeld) hebt afgehandeld.
Maar eigenlijk verschuif je het probleem daarmee, ergens moet je idd iets doen met die exception .

Nee de eerste code gooit de exception gewoon ongewijzigd door. Misschien dat alleen het regelnummer in de stacktrace anders is, maar het gedrag is volgens mij gewoon identiek ( zie het throw keyword ).

Je hebt ook nog de volgende variant

C#:

try{
    //do somehting that throws
}
catch( Exception ex ){
    throw ex;
}

Maar dat is ook nogal zinloos aangezien je dan alleen de stacktrace weg-gooit.

[ Voor 17% gewijzigd door Woy op 07-05-2009 11:04 ]

[.oisyn]

YopY schreef op donderdag 07 mei 2009 @ 09:18:
Mja, dan heb ik liever Java, die de exception 'naar omhoog' gooit ipv dat je dat handmatig moet doen.

Que? Wat bedoel je nou precies? Want ik geloof niet dat C++ of C# ook maar iets anders doen dan Java wat dat betreft.

[Woy]

.oisyn schreef op donderdag 07 mei 2009 @ 11:31:
[...]
Que? Wat bedoel je nou precies? Want ik geloof niet dat C++ of C# ook maar iets anders doen dan Java wat dat betreft.

Behalve dat je bij Java expliciet aan moet geven welke exceptions ( op RuntimeException en sub-classes na ) een methode kan gooien is er bijna geen verschil met het Exceptions systeem in C# inderdaad. Ik denk dat YopY de gedachte heeft dat je bij C# verplicht throw moet doen, maar net zoals bij Java word een exception automatisch door-gegooid op het moment dat je hem niet af-vangt.

[ Voor 31% gewijzigd door Woy op 07-05-2009 11:45 ]

[dj_vibri]

Haan schreef op donderdag 07 mei 2009 @ 09:36:

C#:

public bool CreateFolder(string folderUrl)
{
     string folderpath = GetFolderPath(folderUrl);
     try
      {
           WebRequest request = WebRequest.Create(folderpath);                
           request.Credentials = CredentialCache.DefaultCredentials;
           request.Method = "MKCOL";
           WebResponse response = request.GetResponse();
           response.Close();
           return true;
       }
       catch (WebException)
       {
            return false;
       }
}

Welke versie van SharePoint? Indien wij met folders moeten werken maken we gebruik van o.a. SPSite, SPWeb, SPFolderCollection, GetFolder.Subfolders etc.....

[Haan]

Ik weet niet precies hoe het zit, heb alleen een project afgemaakt dat door iemand anders was gestart. Maar het probleem was volgens mij dat de Microsoft.SharePoint dll alleen te gebruiken was als je ging ontwikkelen op een machine waarop SharePoint geïnstalleerd stond en dat was onhandig. En in de SP webservices (volgens mij moet je dan SPLists hebben) zat geen methode om het bestaan van een folder te checken.
WSS 3.0 gaat het dan om.

[Verwijderd]

Haan schreef op donderdag 07 mei 2009 @ 12:11:
Ik weet niet precies hoe het zit, heb alleen een project afgemaakt dat door iemand anders was gestart. Maar het probleem was volgens mij dat de Microsoft.SharePoint dll alleen te gebruiken was als je ging ontwikkelen op een machine waarop SharePoint geïnstalleerd stond en dat was onhandig. En in de SP webservices (volgens mij moet je dan SPLists hebben) zat geen methode om het bestaan van een folder te checken.
WSS 3.0 gaat het dan om.

Is het de bedoeling van een applicatie zoals een form application of console application te maken want dan moet je inderdaad via webservices werken.
Wanneer je op een server zit te werken om een custom web te maken heb je helemaal geen webservices nodig. Indien je dit even kan verduidelijken kan ik u mss wel helpen

[Verwijderd]

Woy schreef op donderdag 07 mei 2009 @ 11:38:
[...]

Behalve dat je bij Java expliciet aan moet geven welke exceptions ( op RuntimeException en sub-classes na ) een methode kan gooien is er bijna geen verschil met het Exceptions systeem in C# inderdaad. Ik denk dat YopY de gedachte heeft dat je bij C# verplicht throw moet doen, maar net zoals bij Java word een exception automatisch door-gegooid op het moment dat je hem niet af-vangt.

Niet geheel automatisch, je moet zelf immers nog specifieren dat de methode een (of meerdere) exceptions kan throwen .

Wat uiteindelijk dus weer op hetzelfde neerkomt.

[ Voor 13% gewijzigd door Verwijderd op 07-05-2009 13:04 ]

[Woy]

Verwijderd schreef op donderdag 07 mei 2009 @ 13:03:
[...]

Niet geheel automatisch, je moet zelf immers nog specifieren dat de methode een (of meerdere) exceptions kan throwen .

Wat uiteindelijk dus weer op hetzelfde neerkomt.

Dat staat toch juist in mijn post

Behalve dat je bij Java expliciet aan moet geven welke exceptions ( op RuntimeException en sub-classes na ) een methode kan gooien is er bijna geen verschil met het Exceptions systeem in C# inderdaad.

[.oisyn]

Dat zegt Woy toch? Dat je moet aangeven welke exceptions je methode kan gooien. Een division by zero (zoals in het voorbeeld) is echter weer een RuntimeException, en die hoef je niet te specificeren.

Overigens, als ik probeer een exception door te gooien krijg ik een parse error. Kan Java geen exceptions doorgooien? Of verandert de stacktrace niet als je een gevangen exception doorgooit op deze manier:

Java:

try { ... }
catch (Exception e) { throw e; }

.edit: dat kon ik natuurlijk ook wel gewoon even zelf proberen . De stacktrace blijft idd intact.

[ Voor 28% gewijzigd door .oisyn op 07-05-2009 13:13 ]

[Bananenplant]

Haan schreef op donderdag 07 mei 2009 @ 10:42:
[...]

Daar ging het denk ik niet om, maar om het feit dat

C#:

try
{
//doe iets
}
catch (Exception)
{
    throw;
}

gewoon op hetzelfde neerkomt als helemaal geen try/catch blok gebruiken

Heb zoiets wel eens gedaan zodat ik ergens een break point op kon zetten. De Office PIA's vegen excepties namelijk vrolijk onder het kleed, zo kun je ze tenminste nog analyseren ...

[YopY]

Woy schreef op donderdag 07 mei 2009 @ 11:38:
[...]

Behalve dat je bij Java expliciet aan moet geven welke exceptions ( op RuntimeException en sub-classes na ) een methode kan gooien is er bijna geen verschil met het Exceptions systeem in C# inderdaad. Ik denk dat YopY de gedachte heeft dat je bij C# verplicht throw moet doen, maar net zoals bij Java word een exception automatisch door-gegooid op het moment dat je hem niet af-vangt.

^dit. Al is het natuurlijk mogelijk om op een bepaald punt alle exceptions op te vangen en in een 'generiekere' exception te zetten zoals eerder aangegevens is, waardoor je het aaltal exceptions in je method signature weer terug kan brengen.

En ja, dit geldt alleen voor checked exceptions. Je kunt overigens wel unchecked exceptions toevoegen aan je method signature, alleen deze worden genegeerd en hebben geen invloed op je programmacode.

[Verwijderd]

Woy schreef op donderdag 07 mei 2009 @ 13:08:
[...]

Dat staat toch juist in mijn post

[...]

Nee, je stelt dat ze automatisch worden doorgegooid wanneer je ze niet afvangt...maar dat is dus niet zo.

[.oisyn]

Verwijderd schreef op donderdag 07 mei 2009 @ 15:43:
[...]

Nee, je stelt dat ze automatisch worden doorgegooid wanneer je ze niet afvangt...maar dat is dus niet zo.

Dat is wel zo, je hoeft niets af te vangen. De throw specification is een compile-time hindernis die ervoor zorgt dat je geen exceptions mag laten ontsnappen als ze buiten je throw-spec vallen. En door een throw-spec op te geven gooi je ze alsnog niet door. Een exception doorgooien doe je met een throw statement, en vangen doe je met een try/catch blok. Je throw-spec heeft daar niets mee te maken. Dit nog even naast het feit dat unchecked exceptions niet eens een throw-spec nodig hebben.

[ Voor 46% gewijzigd door .oisyn op 07-05-2009 15:58 ]

[Woy]

Verwijderd schreef op donderdag 07 mei 2009 @ 15:43:
[...]
Nee, je stelt dat ze automatisch worden doorgegooid wanneer je ze niet afvangt...maar dat is dus niet zo.

Hoezo worden ze niet automatisch doorgegooid?

edit:
Wat ^^ zegt dus, moet eens refreshen voordat ik reageer

[ Voor 12% gewijzigd door Woy op 07-05-2009 16:07 ]

[CodeCaster]

Nu het hier zo over exceptions gaat, en ik toch voorlopig vanwege stage "vast zit" aan het gebruik van PHP ben ik eens wat gaan aanrommelen met type hinting en foutafhandeling.

Het is in php mogelijk om type hinting te gebruiken bij functies (ook wanneer deze functie een methode in een klasse is):

PHP:

function Foo(Bar $bar)

Wanneer je een verkeerde klasse meegeeft als argument krijg je fijn deze foutmelding:

code:

Catchable fatal error: Argument 1 passed to Foo() must be an instance of Bar, instance of Baz given

Dus, ik schrijf het volgende stukje code:

PHP:

$object = new Baz();

try {
  Foo($object);
} catch (Exception $e) {
  print $e->getTraceAsString();
}

Wat verschijnt er op mijn scherm? Inderdaad, dezelfde foutmelding. Waarom? Hij is toch catchable? Of course not, it's not an exception but just plain and simple error. Zucht.

[Zoijar]

CodeCaster schreef op donderdag 07 mei 2009 @ 16:18:
Wat verschijnt er op mijn scherm? Inderdaad, dezelfde foutmelding. Waarom? Hij is toch catchable? Of course not, it's not an exception but just plain and simple error. Zucht.

Haha, het wordt steeds mooier die taal

[orf]

CodeCaster schreef op donderdag 07 mei 2009 @ 16:18:

Wat verschijnt er op mijn scherm? Inderdaad, dezelfde foutmelding. Waarom? Hij is toch catchable? Of course not, it's not an exception but just plain and simple error. Zucht.

Dan heb je hier misschien iets aan.

[AtleX]

Een catchable fatal error kan je volgens mij wel afvangen met een error handler, terwijl dat met een normale fatal error niet kan.

[.oisyn]

Catchable en fatal klinkt ook nogal tegenstrijdig

[Woy]

Ik zag op php.net dat je het zo makkelijk op kunt lossen

PHP:

function exception_error_handler($errno, $errstr, $errfile, $errline ) {
    throw new ErrorException($errstr, 0, $errno, $errfile, $errline);
}
set_error_handler("exception_error_handler");

Past ook wel weer in dit topic idd

[Zoijar]

een exeption error handler om zowel non-catchable normal errors als catchable fatal errors en normal exceptions af te vangen So much for orthogonality

[AtleX]

.oisyn schreef op donderdag 07 mei 2009 @ 16:26:
Catchable en fatal klinkt ook nogal tegenstrijdig

Nou, het is fatal in de zin dat je code niet doorgaat en de uitvoer, op je error handler na, gestopt wordt. Dat dit een enorm krom systeem is en de naamgeving ruk is ben ik meteen met jou en Zoijar eens.

[Sebazzz]

Tegengekomen in een projectje van een vriend van me...

Visual Basic .NET:

Private Sub Client_Load(ByVal sender As System.Object, _
        ByVal e As System.EventArgs) Handles MyBase.Load
        'Always set to true
        Me.BackgroundWorker1.WorkerReportsProgress = True

        ListBox1.Items.Add("Launching server...")

        *snip*
    End Sub

    Private Sub OnConnect(ByVal AR As IAsyncResult)
        Try
            TCPC.EndConnect(AR)

            Me.BackgroundWorker1.RunWorkerAsync("Connection with server has " & _
            "been established!")

        Catch ex As Exception
            Me.BackgroundWorker1.RunWorkerAsync("Connection failed: " & ex.Message)
        End Try
    End Sub

#Region " Background Worker "
    Private Sub BackgroundWorker1_DoWork(ByVal sender As Object, _
           ByVal e As System.ComponentModel.DoWorkEventArgs) _
               Handles BackgroundWorker1.DoWork
        Me.BackgroundWorker1.ReportProgress(100, e.Argument)
    End Sub

    Private Sub BackgroundWorker1_ProgressChanged(ByVal sender As Object, _
        ByVal e As System.ComponentModel.ProgressChangedEventArgs) _
            Handles BackgroundWorker1.ProgressChanged
        ListBox1.Items.Add(e.UserState) ' WTF is dit²
    End Sub
#End Region

Niet te vergeten 16 timers, één per applicatie dat gecontrolleerd moet worden:

Visual Basic .NET:

    Private Sub timer5_Tick(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Timer5.Tick
        Dim target_hwnd2 As Integer = FindWindow(vbNullString, "Online Soccer Manager | De leukste voetbalmanager! - Microsoft Internet Explorer")
        ' de regel hierboven is één van de twee regels die per timer verschilt
        If (target_hwnd2 = 0) Then
            Exit Sub
        Else
            ' Send the application the WM_CLOSE message.
            PostMessage(target_hwnd2, WM_CLOSE, 0, 0)
            countertimer.Enabled = True
            Dim Writer As New IO.StreamWriter(TCPC.GetStream)
            Dim dateTimeInfo As DateTime = DateTime.Now
            Writer.Write("[" & Now & "] OSM Gevonden op " & Environment.MachineName) 
            ' de regel hierboven is één van de twee regels die per timer verschilt
            Writer.Flush()

            Me.TextBox1.Text = ""
        End If
    End Sub

Lalalalala....

[ Voor 3% gewijzigd door Sebazzz op 20-05-2009 21:45 ]

[Haan]

Kleine uitleg erbij? Bij de tweede lijkt het me dat de else nooit uitgevoerd zal worden. De eerste doet zo te zien wat rare dingen door een ListBox te misbruiken? * Haan kan VB altijd wat lastig lezen

[Gimmeabrake]

Deze vond ik laatst wel erg vermakelijk, moest hem zelf gebruiken:

Visual Basic .NET:

lstObjects.Items(lstObject.Items.IndexOf(SelectedObject)) = SelectedObject

De reden was dat een property van SelectedObject(een zelf-geschreven klasse) was veranderd, waardoor de .ToString() waarde ook veranderde. De listbox gaf echter niet de nieuwe waarde weer, ook niet als ik een .Refresh() of .Update() deed.

[Sebazzz]

Haan schreef op woensdag 20 mei 2009 @ 22:48:
Kleine uitleg erbij? Bij de tweede lijkt het me dat de else nooit uitgevoerd zal worden. De eerste doet zo te zien wat rare dingen door een ListBox te misbruiken? * Haan kan VB altijd wat lastig lezen

Ik schrijf ook geen VB hoor maar het is een application manager, dat moet voorkomen dat medeleerlingen tijdens de les dingen zoals Youtube, World of Warcraft, Online Soccer Manager, Hyves en andere profielsites/videosites/MMORPG draaien. En steeds om de zoveel milliseconden gaat er een timer af die dan controlleert of er een applicatie draait die verboden is. Dit is dan het onderste stuk code.

Het bovenste codeblock is van de serverapplicatie waar dat soort dingen gelogd worden. Die vriend klaagte tegen mij dat de boel langzaam was, dus ik raadde hem aan om een System.Thread of een Backgroundworker te gebruiken voor zware functie calls. Ik geloof alleen niet dat ie doorhad dat BackgroundWorker.OnProgress gewoon op de GUI thread draait

[roy-t]

Sebazzz schreef op donderdag 21 mei 2009 @ 11:31:
[...]
Ik schrijf ook geen VB hoor maar het is een application manager, dat moet voorkomen dat medeleerlingen tijdens de les dingen zoals Youtube, World of Warcraft, Online Soccer Manager, Hyves en andere profielsites/videosites/MMORPG draaien. En steeds om de zoveel milliseconden gaat er een timer af die dan controlleert of er een applicatie draait die verboden is. Dit is dan het onderste stuk code.

Het bovenste codeblock is van de serverapplicatie waar dat soort dingen gelogd worden. Die vriend klaagte tegen mij dat de boel langzaam was, dus ik raadde hem aan om een System.Thread of een Backgroundworker te gebruiken voor zware functie calls. Ik geloof alleen niet dat ie doorhad dat BackgroundWorker.OnProgress gewoon op de GUI thread draait

Niet om het een of ander, maar op die manier websites blokkeren lijkt me wel heel erg onhandig/omslachtig, wat is er mis met de hostfile aanpassen (kost 0,0 cpu cycles) of gaat het hier ook om applicaties zelf? (Ik neem aan dat ze geen installatie rechten hebben?).

[Sebazzz]

roy-t schreef op donderdag 21 mei 2009 @ 11:42:
[...]


Niet om het een of ander, maar op die manier websites blokkeren lijkt me wel heel erg onhandig/omslachtig,

Vandaar die post.

wat is er mis met de hostfile aanpassen (kost 0,0 cpu cycles) of gaat het hier ook om applicaties zelf? (Ik neem aan dat ze geen installatie rechten hebben?).

Het gaat ook om de applicaties zelf. Op die manier worden ook taskmanager en dergelijke geblokkeerd. "Uiteraard" alles met z'n eigen timer. En ja, de gebruikers hebben gewoon volle rechten op de computers, dat is trouwens op mijn school ook zo, want de systeembeheerder is van mening dat zo'n ReBorn/recovery kaartje wel alles veilig houdt op zo'n schoolcomputer.

[RobIII]

roy-t schreef op donderdag 21 mei 2009 @ 11:42:
[...]


Niet om het een of ander, maar op die manier websites blokkeren lijkt me wel heel erg onhandig/omslachtig, wat is er mis met de hostfile aanpassen (kost 0,0 cpu cycles)

Niet om het een of ander, maar ook dat is een bout oplossing want pons een IP in je browser en je bent er al om heen. Er zijn voor dit soort "problemen" vele malen betere oplossingen, maar daar is dit het topic niet voor én dat is iets waar de systeembeheerder van die school iets aan hoort te (kunnen) doen en dan bedoel ik niet het draaien van flutprogramma'tjes geschreven door leerlingen

[SlasZ]

Verwijderd schreef op woensdag 06 mei 2009 @ 23:05:
[...]


Bij bepaalde omstandigheden kan het wel makkelijk zijn om een try te doen met een lege catch
bv met het verwerken van communicatie welke niet altijd goed gaat ivm storing. en dan wil je de gebruiker niet lastig vallen omdat de volgende brok communicatie wel weer goed gaat.

dus ik vind een try met een lege catch niet perse fout

Het is zeer fout tenzij je een zeer specifieke exception catcht, zoals een zelfgemaakte (ConnectionFailedException, ...). Als je alle exceptions zonder meer catcht is het zeer moeilijk debuggen als er bvb ergens een NPE zou optreden die je niet verwacht.

Edit: zoals .oisyn zei dus

[ Voor 32% gewijzigd door SlasZ op 22-05-2009 09:32 ]

[RetroTycoon]

Deze was ook vreselijk om te ontdekken

PHP:

        foreach($xml->user as $gebruiker) {
            $diff = (int)$gebruiker->stats->keys->attributes();

            if($diff > $keys) {
                $podd = $gebruiker->name;
                $diff = $keys;
            }
        }

[ Voor 3% gewijzigd door RetroTycoon op 28-05-2009 17:34 ]

[MBV]

Wat moet het überhaupt doen? De gebruiker zoeken met het hoogste aantal attributen? Ik neem aan dat je $diff en $keys verwisseld hebt, maar ik miste sowieso al een stuk commentaar.

[RetroTycoon]

MBV schreef op donderdag 28 mei 2009 @ 17:42:
Wat moet het überhaupt doen? De gebruiker zoeken met het hoogste aantal attributen? Ik neem aan dat je $diff en $keys verwisseld hebt, maar ik miste sowieso al een stuk commentaar.

Ik dacht, laat ik niet direct de clue weergeven. Maar idd had ik ze omgedraaid, en idd was het de bedoeling dat ik de hoogste waarde eruit zou kunnen plukken

[MBV]

Heb je ooit gehoord van XQuery?

XQuery:

for $user in /user
where $user/stats/keys/@attributeName = max(/user/stats/keys/@attributeName)
return $user/name

Sowieso zit er nog een fout in, want attributes() geeft een array terug. Vandaar dat ik er attributeName in heb gezet.

[ Voor 6% gewijzigd door MBV op 28-05-2009 18:17 ]

[smesjz]

Net op het werk meegemaakt. Een van de programmeurs komt bij mijn bureau en meldt dat een job stuk gelopen is op het mainframe (Cobol) omdat controlegetallen niet kloppen.
De betreffende job gebruikt een dataset die 'mijn' applicatie aanlevert.

Het grote WTF? moment kreeg ik toen ik op zijn output een 'division error' zag. Bij het berekenen van de controlegetallen wordt nergens een deling gemaakt dus toen ik vroeg waar dat vandaan komt: "Ja, de job moet stoppen als de controlegetallen niet kloppen en delen door 0 is dan het makkelijkst".

De betreffende Cobol code heb ik uiteraard niet maar het verbaast me niks als er meer van dit soort gare code gebruikt wordt.

[Remus]

smesjz schreef op woensdag 03 juni 2009 @ 08:24:
Net op het werk meegemaakt. Een van de programmeurs komt bij mijn bureau en meldt dat een job stuk gelopen is op het mainframe (Cobol) omdat controlegetallen niet kloppen.
De betreffende job gebruikt een dataset die 'mijn' applicatie aanlevert.

Het grote WTF? moment kreeg ik toen ik op zijn output een 'division error' zag. Bij het berekenen van de controlegetallen wordt nergens een deling gemaakt dus toen ik vroeg waar dat vandaan komt: "Ja, de job moet stoppen als de controlegetallen niet kloppen en delen door 0 is dan het makkelijkst".

De betreffende Cobol code heb ik uiteraard niet maar het verbaast me niks als er meer van dit soort gare code gebruikt wordt.

Wat ik er van gehoord heb was delen door nul 'vroegâh' een redelijk geaccepteerde methode binnen de COBOL wereld om een process te stoppen bij gebrek aan exceptions ed, dus ik zou de kwaliteit van de rest van de code daar nou niet aan afmeten

[Niemand_Anders]

Nou ja, technisch gezien kun je natuurlijk wel delen door 0. Want als op straat een 6-pack bier ligt en niemand raapt het op en het dus door niemand wordt verdeelt, dan heeft iedereen niets (nul) gekregen. Je zou dus kunnen zeggen dat als je iets deelt door 0 je niets overhoud..

Valt een beetje in dezelfde category als maakt een omvallende boom lawaai als er niemand in de buurt is..

[mcDavid]

Niemand_Anders schreef op woensdag 03 juni 2009 @ 09:11:
Nou ja, technisch gezien kun je natuurlijk wel delen door 0. Want als op straat een 6-pack bier ligt en niemand raapt het op en het dus door niemand wordt verdeelt, dan heeft iedereen niets (nul) gekregen. Je zou dus kunnen zeggen dat als je iets deelt door 0 je niets overhoud..

Valt een beetje in dezelfde category als maakt een omvallende boom lawaai als er niemand in de buurt is..

Het is een puur wiskundige berekening, en wiskundig gezien is delen door 0 onmogelijk.

Praktisch ook. Je kunt die sixpack niet over 0 personen verdelen. Hoe je erbij komt dat "iedereen" niets heeft zonder dat er uberhaupt een "iedereen" bestaat is me niet helemaal duidelijk. Precies de reden dat het niet mogelijk is.

[YopY]

Niemand_Anders schreef op woensdag 03 juni 2009 @ 09:11:
Nou ja, technisch gezien kun je natuurlijk wel delen door 0. Want als op straat een 6-pack bier ligt en niemand raapt het op en het dus door niemand wordt verdeelt, dan heeft iedereen niets (nul) gekregen. Je zou dus kunnen zeggen dat als je iets deelt door 0 je niets overhoud..

Valt een beetje in dezelfde category als maakt een omvallende boom lawaai als er niemand in de buurt is..

Dan heeft niemand niks gekregen, aangezien er niemand is die de sixpack wil hebben, . Een getal delen door 0 kan niet, aangezien 0 nooit in een getal past, en aldus de uitkomst van getal / 0 oneindig + 1 zou zijn (oid).

Maar hoe om te gaan met delen door 0 is afhankelijk van de omgeving, zie ook Wikipedia: Division by zero. Als het je lukt zal het universum instorten, wees dus wel voorzichtig .

[HawVer]

Niemand_Anders schreef op woensdag 03 juni 2009 @ 09:11:
Nou ja, technisch gezien kun je natuurlijk wel delen door 0. Want als op straat een 6-pack bier ligt en niemand raapt het op en het dus door niemand wordt verdeelt, dan heeft iedereen niets (nul) gekregen. Je zou dus kunnen zeggen dat als je iets deelt door 0 je niets overhoud..

Valt een beetje in dezelfde category als maakt een omvallende boom lawaai als er niemand in de buurt is..

Nee het valt in de categorie, een boom die niet omvalt maakt ook geen lawaai. Als je niemand iets uitdeelt ben je ook niet aan het delen... Bijvoorbeeld 10 gedeeld door 2 levert 5 keer een subset op van 2. Als ik tien deel door nul hoe vaak krijg ik dan een subset van 0? Het zou dus eerder oneindig zijn dan nul. Iets dat oneindig oplevert heeft weinig betekenis? Wat kun je er mee?

[XWB]

Niemand_Anders schreef op woensdag 03 juni 2009 @ 09:11:
Nou ja, technisch gezien kun je natuurlijk wel delen door 0. Want als op straat een 6-pack bier ligt en niemand raapt het op en het dus door niemand wordt verdeelt, dan heeft iedereen niets (nul) gekregen. Je zou dus kunnen zeggen dat als je iets deelt door 0 je niets overhoud..

Valt een beetje in dezelfde category als maakt een omvallende boom lawaai als er niemand in de buurt is..

Dat is helemaal niet dezelfde vergelijking!

mcDavid schreef op woensdag 03 juni 2009 @ 09:33:
[...]

Het is een puur wiskundige berekening, en wiskundig gezien is delen door 0 onmogelijk.

De uitkomst is oneindig. Limieten vond ik altijd leuke leerstof

[XWB]

In België werd ons oneindig geleerd

[RobIII]

Crap; anders delete ik even m'n eigen post te vlug

Anyhow: het is nogal afhankelijk van de context waarin je het gebruikt. In doordeweekse zaken is delen door nul gewoon ongedefinieerd.

quote: http://en.wikipedia.org/wiki/Divide_by_zero#In_algebra

It is generally regarded among mathematicians that a natural way to interpret division by zero is to first define division in terms of other arithmetic operations. Under the standard rules for arithmetic on integers, rational numbers, real numbers and complex numbers, division by zero is undefined. Division by zero must be left undefined in any mathematical system that obeys the axioms of a field. The reason is that division is defined to be the inverse operation of multiplication. This means that the value of a/b is the solution x of the equation bx = a whenever such a value exists and is unique. Otherwise the value is left undefined.

[mcDavid]

Hacku schreef op woensdag 03 juni 2009 @ 09:42:
[...]


Dat is helemaal niet dezelfde vergelijking!


[...]


De uitkomst is oneindig. Limieten vond ik altijd leuke leerstof

Bij delen door oneindig klein is de uitkomst oneindig, bij delen door nul is er géén uitkomst.

[ Voor 3% gewijzigd door mcDavid op 03-06-2009 10:02 ]

[.oisyn]

Euh nee, bij delen door oneindig is de uitkomst 0. Wiskundig is x / 0 ongedefinieerd, maar in bepaalde toepassingsgebieden waarin met oneindigheden gerekend wordt geldt x / 0 = ∞ voor x > 0 en -∞ voor x < 0. Als x = 0 is het altijd ongedefinieerd. Verder is x / ∞ gelijk aan 0, tenzij x = ∞ of x = -∞, dan is het ongedefinieerd. Dit zijn ook de regels die het IEEE floating point formaat aanhoudt

[ Voor 4% gewijzigd door .oisyn op 03-06-2009 10:59 ]

[Verwijderd]

inderdaad, .oisin heeft gelijk.
De meesten maken de fout door de limiet x->0 (x nadert 0) gelijk te stellen aan x = 0. Voor x gaat naar oneindig klopt dit meestal wel overigens.

Dit kan ook bewezen worden dmv de vergelijking. Bv y = 1/x
Stellen we x gelijk aan 0, dan vinden we geen waarde. Dit is dan ook de reden waarom nulpunten van de teller niet tot het domein behoren van de vergelijking.

[NielsNL]

Zelf geschreven vode om door een array heen te lopen en daar een <ul> met sub <ul>'s van te maken.

code:

$result[]:
map0
map1 - pagina1
map1 - pagina2
map2 - pagina3
map3
map4 - pagina4
enz...

PHP:

$prev_dirname = "none";
$prev_sublist = false;
$made_sublist = false;
echo "<ul id=\"nav\">\n"; //ul wrapper
while($row = $result->fetch_array()){
    if(($prev_dirname !== "none") && ($prev_dirname !== $row['dirname'])){
        if($prev_sublist){
            if($made_sublist){
                echo "  </ul>\n";
                $made_sublist = false;
            }
            echo "</li>\n";
        }
    }
    
    if(empty($row['pagename'])){
        echo "<li id=\"nav_".$row['dirid']."\"><a href=\"./".$row['dirname']."/\">".$row['dirname']."</a></li>\n"; //single folder, no items
        $prev_sublist = false;
    }else{
        if($prev_dirname != $row['dirname']){
            echo "<li id=\"nav_".$row['dirid']."\"><a href=\"./".$row['dirname']."/\">".$row['dirname']."</a>\n"; //this is the first item, make folder link.   
        }
        if($row['dirname'] != $row['pagename']){
            if(!$made_sublist){
                echo "  <ul>\n";
                $made_sublist = true;
            }
            echo "      <li><a href=\"./".$row['dirname']."/".$row['pagename']."/\">".$row['pagename']."</a></li>\n";
        }
        $prev_sublist = true;
    }
    $prev_dirname = $row['dirname']; //set for checking in next row
}
if($prev_sublist == true){
    echo "  </ul>\n";
    echo "</li>\n";
};
echo "</ul>\n";

Ik vind het teveel code voor zoiets simpels, maar het werkt prima.

[roy-t]

@NielsNL

Dat heb ik ook wel eens, heel veel code voor iets ongenschijnlijks heel simpels. Ik had bijvoorbeeld code geschreven om de muis op het scherm te houden in een programma. Heel ingewikkeld gedaan met nested if's.

Kwam ik er uit eindelijk achter dat je met zoiets als

C#:

if(cursor.left > border.left/2)
{
    cursor.left=Math.Min(cursor.left, border.left) ;
}
else
{
    cursor.left=Math.Max(cursor.left, 0);
}

En dat nog een keer voor de hoogte alles is wat je nodig hebt. (geloof me, mijn code was laaaaaaaaaannnnggg).

[.oisyn]

Ik vind je code nog steeds een beetje raar. Waarom zou je moeten testen aan welke kant van het midden hij zit? Je zou de if ook zo kunnen schrijven:

C#:

if(cursor.left > border.left) 
{ 
    cursor.left = border.left; 
} 
else if (cursor.left < 0)
{ 
    cursor.left = 0; 
}

En als je dan idd Min en Max toepast, wat idd handig is, waarom überhaupt nog die if?

C#:

cursor.left = Math.Min(Math.Max(cursor.left, 0), border.left);

En als je dat soort code vaak gebruikt (zoals ik), dan maak je er een functie van:

C#:

cursor.left = Clamp(cursor.left, 0, border.left);

[ Voor 255% gewijzigd door .oisyn op 04-06-2009 11:28 ]

[netvor]

De implementatie van de IEEE 754 floats is een mooi voorbeeld van de kloof tussen harde wiskunde en toegepaste wiskunde. Binnen de reële getallen bestaat er geen delen door nul, we kunnen slechts met limieten werken om er iets zinnigs over te kunnen zeggen. De ingenieurs van het IEEE team hebben vervolgens dus hun eigen regels opgesteld en simpele regels omtrent 0,1,Inf en NaN vastgelegd.

Een interessant gevolg hiervan is dat de floats géén "field" (dat heet dacht ik "lichaam" in het Nederlands) vormen, omdat de twee Inf's en de NaN geen inverses hebben. De int's (met wraparound, zoals in C) zijn dat wel, mede omdat delen door nul je daar een mooie errormessage/exception/BSOD geeft.

[ Voor 3% gewijzigd door netvor op 04-06-2009 11:38 . Reden: Bij nader inzien is dat niet de reden dat het een field is... ]

[MBV]

Ik denk dat die IEEE regels ook komen doordat floats per definitie onnauwkeurig zijn: als iets 0 is, is het eigenlijk een oneindig klein getal toch?

[.oisyn]

Nee hoor 0 is gewoon 0. Okee, je hebt dan wel +0 en -0 . Er is geen manier om infinitesimals op te slaan. Voor de 32 bits floats, onder de 2^-126 bevinden zich de subnormal numbers, waarbij de mantissa z'n expliciete 1 voor de komma verliest. Als je de mantissa dan op 0 zet dan wordt die waarde dan ook echt 0 (en niet heel klein oid)

[ Voor 124% gewijzigd door .oisyn op 04-06-2009 12:17 ]

[MBV]

Volgens mij niet. Bij een floating point getal betekent waarde 0,0000001 toch dat de waarde tussen 0,00000005 en 0,00000015 ligt? Betekent +0,0000000 dan niet dat de waarde tussen +0,00000000000001 en +0,00000005 ligt?

Als 0 gewoon 0 is, dan mag je dit doen:

C:

float x = doSomething();
if (x == 0) {
 ...
}

En ik had altijd begrepen dat dat 'not done' is bij floats, dat je altijd een range moet pakken.

[.oisyn]

Dat een uitkomst niet exact hoeft te zijn betekent niet meteen dat een 0 geen 0 meer is. 3 * 3 is gewoon 9, 16 / 2 gewoon 8, en 0 * x is gewoon 0. Alleen niet alles past in een float, en daar moet je rekening mee houden met je berekeningen en vergelijkingen. Als het expected is dat doSomething() in sommige gevallen exact 0 teruggeeft, dan kun je daar gewoon op vergelijken (overigens zijn +0 en -0 gelijk aan elkaar volgens de IEEE regels, dus daar hoef je je geen zorgen over te maken).

Betekent +0,0000000 dan niet dat de waarde tussen +0,00000000000001 en +0,00000005 ligt?

Nou dat lijkt me sowieso een beetje raar, de waarde 0 zelf moet iig ook in de range zitten. En wellicht wil je een paar negatieve waarden bij de range stoppen, afhankelijk van je berekening (bijv. wel voor optellen/aftrekken, maar weer niet voor delen/vermenigvuldigen). De grootte van je range hangt ook af van hoeveel berekeningen je gedaan hebt.

Meestal vergelijk je idd met een orde-van-grootte afhankelijke epsilon. Kort door de bocht kun je (a == b) beter schrijven als (abs(a-b) < (abs(a) + abs(b)) * eps), waarbij eps je (relatieve) foutmarge is, zoals bijv. 1e-8 (wat betekent dat voor getallen rond 1 ze 1e-8 mogen afwijken, maar voor getallen rond 1000 mogen ze 1e-5 afwijken, etc). Maar de daadwerkelijke waarde van eps die je moet gebruiken hangt nogal af van hoe a en b tot stand zijn gekomen. Als het direct user-invoer is kun je een hele kleine epsilon gebruiken. Zijn ze echter het gevolg van een ellenlange berekening, dan is eps afhankelijk van elke afzonderlijke input in die berekening, en wat voor operaties er in die berekening zitten.

[ Voor 51% gewijzigd door .oisyn op 04-06-2009 12:35 ]

[roy-t]

.oisyn schreef op donderdag 04 juni 2009 @ 11:21:
Ik vind je code nog steeds een beetje raar. Waarom zou je moeten testen aan welke kant van het midden hij zit? Je zou de if ook zo kunnen schrijven:

C#:

if(cursor.left > border.left) 
{ 
    cursor.left = border.left; 
} 
else if (cursor.left < 0)
{ 
    cursor.left = 0; 
}

En als je dan idd Min en Max toepast, wat idd handig is, waarom überhaupt nog die if?

C#:

cursor.left = Math.Min(Math.Max(cursor.left, 0), border.left);

En als je dat soort code vaak gebruikt (zoals ik), dan maak je er een functie van:

C#:

cursor.left = Clamp(cursor.left, 0, border.left);

Ik heb de code nog even bekeken en ik heb inderdaad die one-line versie gebruikt slordig dat ik dat nu niet weer meteen zag. (Verder is een clamp functie natuurlijk altijd handig)

[Gimmeabrake]

kwam ik net tegen in mijn eigen code:

Visual Basic .NET:

Public Sub UpdateCall()
   [...code...]
   If intCallIndex = -1 Then Exit Sub
End Sub

Waarschijnlijk is die regel bij het herschrijven van de sub overgebleven... anders snap ik niet hoe ik deze code heb kunnen verzinnen

[Haan]

Het idee is opzich toch niet zo raar? Alleen jammer van het '='je dat je bent vergeten

[Woy]

Welk '='je dat hij vergeten is?

Het vreemde is dat de Exit Sub als laatste van de Sub uitgevoerd word, wat dus effectief niks doet.

[ Voor 62% gewijzigd door Woy op 04-06-2009 16:18 ]

[Haan]

Woy schreef op donderdag 04 juni 2009 @ 16:18:
Welk '='je dat hij vergeten is?

Werkt dat in VB niet zo dan? (het feit dat je in C gebaseerde talen met if (x = 1) { } de waarde van x op 1 zou zetten, en dus if (x ==1 ) { } zou moeten gebruiken.

Het vreemde is dat de Exit Sub als laatste van de Sub uitgevoerd word, wat dus effectief niks doet.

Dat is inderdaad wel een jammerlijk

[Woy]

Haan schreef op donderdag 04 juni 2009 @ 16:41:
[...]
Werkt dat in VB niet zo dan? (het feit dat je in C gebaseerde talen met if (x = 1) { } de waarde van x op 1 zou zetten, en dus if (x ==1 ) { } zou moeten gebruiken.

In VB(.NET) is de = zowel de assignment als de comparison operator. In deze context is het dus gewoon de comparison operator.

In C# en Java zou het overigens niet compilen aangezien het niet naar bool evalueert, dus dan kan je ook niet per ongeluk assignen in plaats van comparen.

[ Voor 16% gewijzigd door Woy op 04-06-2009 16:51 ]

[Gimmeabrake]

Woy schreef op donderdag 04 juni 2009 @ 16:18:
Welk '='je dat hij vergeten is?

Het vreemde is dat de Exit Sub als laatste van de Sub uitgevoerd word, wat dus effectief niks doet.

My thoughts exactly, je slaat de spijker op z'n kop

[.Gertjan.]

Woy schreef op donderdag 04 juni 2009 @ 16:49:
[...]

In VB(.NET) is de = zowel de assignment als de comparison operator. In deze context is het dus gewoon de comparison operator.

In C# en Java zou het overigens niet compilen aangezien het niet naar bool evalueert, dus dan kan je ook niet per ongeluk assignen in plaats van comparen.

En anders kan je altijd nog de constructie

code:

if (1 == variable) { }

gebruiken.

In dat geval zit je altijd goed (of je moet in c++ een assignment willen doen, dan gaat dit natuurlijk niet). Uiteraard valt er hier te discussiëren over de leesbaarheid, maar dit is een tip die ik ooit kreeg en je ziet hem geregeld langskomen.

Maar uit automatisme (en voor de betere leesbaarheid) gebruik ik zelf toch meestal

code:

if (variable == 1) { }

. Dit komt meer overeen met hoe je in het "normale" leven spreekt. Daar ze je ook "als de snelheid 120 km/h is" en niet "als 120km/h de snelheid is".

Overigens geven sommige C++ compilers wel een warning als je slechts een = gebruikt.

[Matis]

.Gertjan. schreef op vrijdag 05 juni 2009 @ 08:47:

code:

if (variable == 1) { }

. Dit komt meer overeen met hoe je in het "normale" leven spreekt. Daar ze je ook "als de snelheid 120 km/h is" en niet "als 120km/h de snelheid is".

Yup doe ik vrijwel altijd zo.

Daarnaast is het soms lastig dat een int niet gelijk aan 0 niet gewoon als true door het leven kan gaan binnen java/C++ etc.

C:

int variabele = 0;
//nog meer code, waar misschien variabele gewijzigd wordt
if(variabele)
{
   // variabele is gewijzigd
}
else
{
   // niet dus
}

Persoonlijk zou ik dit wel fijn vinden, maar enfin. By design is daar dus niet voor gekozen

[Mammon]

dan pas je het if-statement toch een heel klein beetje aan

Java:

int variabele = 0; 
//nog meer code, waar misschien variabele gewijzigd wordt 
if(variabele!=0) 
{ 
   // variabele is gewijzigd 
} 
else 
{ 
   // niet dus 
}

[Janoz]

Matis schreef op vrijdag 05 juni 2009 @ 08:57:

Daarnaast is het soms lastig dat een int niet gelijk aan 0 niet gewoon als true door het leven kan gaan binnen java/C++ etc.

In C wel, maar Java iig niet:

code:

~$ cat Test.java
public class Test {

        public static void main (String[] args) {
                int i=0;
                if (i) {
                        System.out.println("ja");
                } else {
                        System.out.println("nee");
                }
        }
}
~$ javac Test.java
Test.java:5: incompatible types
found   : int
required: boolean
                if (i) {
                    ^
1 error

[.Gertjan.]

Matis schreef op vrijdag 05 juni 2009 @ 08:57:
[...]


Yup doe ik vrijwel altijd zo.

Daarnaast is het soms lastig dat een int niet gelijk aan 0 niet gewoon als true door het leven kan gaan binnen java/C++ etc.

C:

int variabele = 0;
//nog meer code, waar misschien variabele gewijzigd wordt
if(variabele)
{
   // variabele is gewijzigd
}
else
{
   // niet dus
}

Persoonlijk zou ik dit wel fijn vinden, maar enfin. By design is daar dus niet voor gekozen

Het zou ook fijn zijn als je de if ook kunt gebruiken voor == null vergelijkingen zonder de ==null te hoeven in vullen. In JavaScript kan dat dus wel. Daar kun je dus constructies maken als:

JavaScript:

if (myVar) { 
  //Var !=null
} else {
  //Var ==null
}

Als ik een tijdje wat frontend werk heb gedaan probeer ik dat dus ook toe te passen in C# om vervolgens na ruzie met de compiler te krijgen (en pas na een tijdje zien wat je fout hebt gedaan).

Maar goed dat heb ik wel vaker. Als ik switch tussen VB.NET en C# ga ik in C# Dim gebruiken en in VB

Visual Basic .NET:

MyClass obj = new MyClass();

[.oisyn]

Woy schreef op donderdag 04 juni 2009 @ 16:49:
In C# en Java zou het overigens niet compilen aangezien het niet naar bool evalueert, dus dan kan je ook niet per ongeluk assignen in plaats van comparen.

In die context niet, maar met booleans natuurlijk weer wel.

[.Gertjan.]

.oisyn schreef op vrijdag 05 juni 2009 @ 11:25:
[...]

In die context niet, maar met booleans natuurlijk weer wel.

Is dat zo? Is het result van een assignment dan de waarde die je assigned of komt er bijvoorbeeld in C# niets uit? In dat laatste geval zou het dus niet kunnen. Ben ik eigenlijk wel benieuwd naar...

[Grijze Vos]

.Gertjan. schreef op vrijdag 05 juni 2009 @ 11:56:
[...]


Is dat zo? Is het result van een assignment dan de waarde die je assigned of komt er bijvoorbeeld in C# niets uit? In dat laatste geval zou het dus niet kunnen. Ben ik eigenlijk wel benieuwd naar...

Uit de grammatica van C#:

code:

expression:
  conditional-expression
  assignment

Dus ja, een assignment is een expressie, en heeft dus een result waarde.

[YopY]

quote: matis

Daarnaast is het soms lastig dat een int niet gelijk aan 0 niet gewoon als true door het leven kan gaan binnen java/C++ etc.

quote: .Gertjan.

Het zou ook fijn zijn als je de if ook kunt gebruiken voor == null vergelijkingen zonder de ==null te hoeven in vullen. In JavaScript kan dat dus wel. Daar kun je dus constructies maken als:

Beide posts geciteerd even. Het punt hier is dat een boolean iets fundamenteel anders is dan een getal of 'null'. Met een boolean geef je true of false aan, niet 3000 of 'niks'. Dat is dan ook een feature van bepaalde talen (C, Javascript, PHP) waar ik het niet mee eens ben.

Een boolean is een concept op zich, vindt ik, en als je een vergelijking wilt doen (if), moet je dat op een echte boolean doen, niet op een cijfer of iets dat 'niet null' moet zijn.

[.oisyn]

Grijze Vos schreef op vrijdag 05 juni 2009 @ 12:31:
[...]

Uit de grammatica van C#:

code:

expression:
  conditional-expression
  assignment

Dus ja, een assignment is een expressie, en heeft dus een result waarde.

Dat zegt niets, het resultaat van de expressie kan ook void zijn, zoals bijv. bij een functie die niets retourneert . Maar bij assignments is het resultaat de variabele waaraan je zojuist geassigned hebt, zodat je kunt doen

C#:

a = b = c = 34;

(En aangezien de assignment right-associative is, wordt dat geparsed als a = (b = (c = 34)))

[ Voor 12% gewijzigd door .oisyn op 05-06-2009 16:20 ]

[Verwijderd]

Ik ben nu een web applicatie aan het nakijken, welke is gemaakt in Visual Studio 2003. Ik lach me dood om de
<p></p><blockquote></blockquote> en als klap op de vuurpijl   reeksen met aan het einde daarvan een <br>

en daar 1200 regels van

[.Gertjan.]

Verwijderd schreef op vrijdag 05 juni 2009 @ 16:28:
Ik ben nu een web applicatie aan het nakijken, welke is gemaakt in Visual Studio 2003. Ik lach me dood om de
<p></p><blockquote></blockquote> en als klap op de vuurpijl   reeksen met aan het einde daarvan een <br>

en daar 1200 regels van

Waarschijnlijk autogenerated code van Visual Studio. Ik moet zeggen dat VS er een handje van heeft om bagger te maken. Vooral de oudere versies. 2008 geeft wel aardige HTML (ook als je "sleur en pleur" gebruikt).

Maar soms zet ik toch mijn vraagtekens bij HTML generatie van VS. Zo wordt een ASP:CheckBox altijd gerenderd als:

XHTML:

<span class="cssClass"><input type="checkbox" name="xxx" /></span>

Waarbij alle attributen die je toekent aan de checkbox op de bovenliggende span worden toegepast. Als je dan een hele pagina aan het stylen bent en er vanuit gaat dat alles op de input wordt gezet (en daar ook je CSS op baseert) is het toch wel even een kleine WTF wanneer je gaat runnen.

Vanwege die reden pas ik de rendering van bepaalde controls aan en gebruik ik eigenlijk sowieso zo min mogelijk .NET controls. Maar goed dat is ook een beetje mijn frontend achtergrond en mijn eigenwijsheid

Zat in VS 2003 trouwens niet de "sleur en pleur" engine van Frontpage? Overigens was VS 2003 / .NET ook erg vervelend tegen niet IE browsers (bepaalde attributen zoals width werden niet aan browsers anders dan IE doorgegeven, moest je weer met een browser file op je website aan de gang...

[mithras]

.Gertjan. schreef op zaterdag 06 juni 2009 @ 12:22:
[...]
Vanwege die reden pas ik de rendering van bepaalde controls aan en gebruik ik eigenlijk sowieso zo min mogelijk .NET controls. Maar goed dat is ook een beetje mijn frontend achtergrond en mijn eigenwijsheid

Heb je niet de mogelijkheid om op elementen een decorator toe te passen? Het is een beetje een andere scope, maar in het Zend Framework kan je alle onderdelen binnen Zend_Form (dus het formulier inclusief alle inputs) stylen met zogenaamde decorators: http://framework.zend.com...end.form.forms.decorators.

Zo kan je heel snel een eigen opmaak genereren (maar de standaard is al heel erg goed eigenlijk). Dan hoef ik niet allemaal eigen elementen te maken gelukkig

[Matis]

mithras schreef op zaterdag 06 juni 2009 @ 12:33:
Heb je niet de mogelijkheid om op elementen een decorator toe te passen? Het is een beetje een andere scope, maar in het Zend Framework kan je alle onderdelen binnen Zend_Form (dus het formulier inclusief alle inputs) stylen met zogenaamde decorators: http://framework.zend.com...end.form.forms.decorators.

Zo kan je heel snel een eigen opmaak genereren (maar de standaard is al heel erg goed eigenlijk). Dan hoef ik niet allemaal eigen elementen te maken gelukkig

Alhoewel dit niets met slechte programmeervoorbeelden te maken heeft zweer ik ook bij het hele Zend Framework. De ondersteuning is enorm en de toepasbaarheid wordt steeds beter. Het maken van een form met render/opmaak-scope en validator kost wat moeite, maar als je het eenmaal onder de knie hebt, fabriceer je de mooiste forms!

offtopic:
Misschien een keer tijd voor deel 5?

[ Voor 3% gewijzigd door Matis op 06-06-2009 12:37 ]

[Tanuki]

Matis schreef op zaterdag 06 juni 2009 @ 12:37:

offtopic:
Misschien een keer tijd voor deel 5?

Waarom dan?

[Matis]

l0c4lh0st schreef op zaterdag 06 juni 2009 @ 14:10:
[...]

Waarom dan?

1000 berichten, dacht dat dat de richtlijn was binnen PRG;

Bron

[ Voor 57% gewijzigd door Matis op 06-06-2009 14:27 ]

[Verwijderd]

offtopic:
*kick , nog geen deeltje 5?

Kwam vandaag het volgende tegen...(letterlijk, op de url na)

Eerst een gewoon <form> met een submit en een action e.d. met daarna dit om naar een vorige pagina te gaan.

HTML:

<form>
    <a href="een_vorige_pagina.html">
        <input type="image" src="knopje.gif">
    </a>
</form>

Das toch raarrr? (raar genoeg werkt dit alleen in IE niet?)

[MBV]

Het is inderdaad raarrrr, en ik heb geen idee van de semantiek: moet je nu naar de action van het form toegaan, of naar de href van de anchor?

Hij validate wel, als je een action aan de form toevoegt (en natuurlijk doctype, head en andere meuk toevoegt):

HTML:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
   "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head><title>something</title></head>
<body>
<form action="somethingelse">
  <a href="something">
    <input type="button">
  </a>
</form>
</body>
</html>

[Verwijderd]

MBV, je mist iets:

Verwijderd schreef op dinsdag 23 juni 2009 @ 21:08:
... Eerst een gewoon <form> met een submit en een action e.d. met daarna dit om naar een vorige pagina te gaan...

En ja: dat is een beetje vreemd.

[ Voor 10% gewijzigd door Verwijderd op 24-06-2009 10:20 ]