[alg] slechtste prog voorbeelden.

[Sybr_E-N]

HIGHGuY schreef op vrijdag 31 maart 2006 @ 22:22:
code van een docent van me:

C#:

private void Page_Load(object sender, System.EventArgs e)

ja, alles werkt...

tot er 2 gebruikers tegelijk de pagina laden...

En dan je DataAdapter opslaan in de Application cache . Hele datasets in je ViewState

Ik hoop voor je dat de leraar dit soort praktijken niet verplicht stelt

[H!GHGuY]

Japie_17 schreef op vrijdag 31 maart 2006 @ 22:35:
[...]

In C++ geeft dat altijd true, maar ik geloof dat je gelijk hebt voor PHP .

in C++ geeft dit false ??

a = 0 evalueert naar 0
0 is nog altijd false

[H!GHGuY]

Sybr_E-N schreef op vrijdag 31 maart 2006 @ 22:38:
[...]

En dan je DataAdapter opslaan in de Application cache . Hele datasets in je ViewState

Ik hoop voor je dat de leraar dit soort praktijken niet verplicht stelt

zoals ik daarpas op dailywtf tegenkwam:
"monkey-see-monkey-do"
er is niemand die van beter weet.

Ik heb haar lessen al enkele keren onderbroken om te zeggen dat haar voorbeelden echt tegen alle regels zondigen, maar dan zegt ze: "ik wou enkel dit of dat aantonen"

Ze geeft ook Java. Toegegeven, ik acht haar Java-skills groter. maar Java in .NET proberen te schrijven is echt je reinste BS.µ

edit: ik had op de vorige post ook een edit moeten doen... sorry

[ Voor 7% gewijzigd door H!GHGuY op 31-03-2006 22:54 ]

[Erkens]

OlafvdSpek schreef op vrijdag 31 maart 2006 @ 21:47:
[...]

Volgens mij is if (a = 0) gewoon false hoor.

Je hebt natuurlijk helemaal gelijk, ik was even in de war, ik dacht dat aangezien een toekenning (over het algemeen) altijd goed gaat dat er true uit zou komen
Terwjil in werkelijkheid, de toegekende waarde wordt ge-returned (in de meeste talen) wat behalve 0 en null etc altijd naar true evalueert

[Jaap-Jan]

HIGHGuY schreef op vrijdag 31 maart 2006 @ 22:50:
[...]


in C++ geeft dit false ??

a = 0 evalueert naar 0
0 is nog altijd false

Sorry, ik had dat al aangepast. Ik meende dat me daar iets van bij stond, maar dat is dus niet zo .

[JKVA]

OlafvdSpek schreef op vrijdag 31 maart 2006 @ 20:26:
[...]

Inderdaad door de variabele scope.

[...]

Voor lokale variabelen hoef je toch niet te wachten op de garbage collector.

Je moet voor alles wachten op de garbage collector. Het belangrijkste dat je moet weten van de garbage collector in Java is dat je nooit weet wanneer je objecten daadwerkelijk weg zijn. Gelukkig hoef je dat ook niet te weten, waardoor je jezelf bezig kan houden met de code specifiek voor je project in plaats van overhead zoals geheugenmanagement.

Over die connecties. Gewoon op null zetten is idd niet voldoende om een connectie met de database te sluiten. Haal voor de grap maar eens een finally weg en maak tig statements aan. De meeste DBMS-en vinden dit niet leuk.

[Olaf van der Spek]

JKVA schreef op zondag 02 april 2006 @ 11:24:
Je moet voor alles wachten op de garbage collector. Het belangrijkste dat je moet weten van de garbage collector in Java is dat je nooit weet wanneer je objecten daadwerkelijk weg zijn.

Gelukkig hoef je dat ook niet te weten, waardoor je jezelf bezig kan houden met de code specifiek voor je project in plaats van overhead zoals geheugenmanagement.

Maar met 'handle' management/overhead (database, file en netwerk connecties) moet je je dus wel bezig houden. En exception safe is de code ook niet (er treden resource leaks op).

[ Voor 7% gewijzigd door Olaf van der Spek op 02-04-2006 11:50 ]

[JKVA]

OlafvdSpek schreef op zondag 02 april 2006 @ 11:41:
[...]



[...]

Maar met 'handle' management/overhead (database, file en netwerk connecties) moet je je dus wel bezig houden. En exception safe is de code ook niet (er treden resource leaks op).

Helemaal waar. Dat is ook een van de redenen dat ik het Spring framework zo cool vind. Dan worden die zaken allemaal voor je afgeschermd en ben je alleen lekker aan het querien, zonder try-catch-finally gezeur.

Ps. Die resource leaks staan vrij los van de taal Java an sich. Naar mijn idee, als je met meerdere programma's naast elkaar draait en die moeten met elkaar samenwerken, loop je altijd het risico op lekken en zo.

[Not Pingu]

HIGHGuY schreef op vrijdag 31 maart 2006 @ 22:22:

code van m'n medestudenten tijdens het project dat hierop volgt (niet exact, losse pols)

C#:

      try
      {
          return adapter.SelectCommand.ExecuteScalar().ToString();
      }
      finally
      {
         conn.Close()
      }

Wordt de finally statement wel uitgevoerd als je al returnt uit de functie? Anders wordt die connection dus alleen afgesloten als er een fout optreedt bij het uitvoeren van de query

[Olaf van der Spek]

Gunp01nt schreef op zondag 02 april 2006 @ 13:08:
Wordt de finally statement wel uitgevoerd als je al returnt uit de functie? Anders wordt die connection dus alleen afgesloten als er een fout optreedt bij het uitvoeren van de query

Dat is toch het hele idee van finally (in tegenstelling tot catch)?

[Olaf van der Spek]

JKVA schreef op zondag 02 april 2006 @ 12:01:
Ps. Die resource leaks staan vrij los van de taal Java an sich. Naar mijn idee, als je met meerdere programma's naast elkaar draait en die moeten met elkaar samenwerken, loop je altijd het risico op lekken en zo.

Waarom zou dat zo zijn?
Een programma kan er toch altijd zelf voor zorgen dat het zeker zijn connecties sluit?

[Not Pingu]

OlafvdSpek schreef op zondag 02 april 2006 @ 13:26:
[...]

Dat is toch het hele idee van finally (in tegenstelling tot catch)?

Maar omdat je binnen de try{} returned spring je uit de functie. Als je het volgende doet:

C#:

  for(int i = 1; i <= 10; i++)
  {
    return "bla";
  }

dan gaat de for loop volgens mij ook maar 1x af en wordt ie niet verder uitgevoerd. Ik weet niet zeker hoe dat met try-catch-finally zit, maar het lijkt me dat als je binnen de try uit de method springt, de finally niet meer uitgevoerd wordt.

Heb hier geen Visual C# express op deze pc dus ik kan het zo gauw niet controleren.

[Salandur]

Gunp01nt schreef op zondag 02 april 2006 @ 15:40:
[...]


Maar omdat je binnen de try{} returned spring je uit de functie. Als je het volgende doet:

C#:

  for(int i = 1; i <= 10; i++)
  {
    return "bla";
  }

dan gaat de for loop volgens mij ook maar 1x af en wordt ie niet verder uitgevoerd. Ik weet niet zeker hoe dat met try-catch-finally zit, maar het lijkt me dat als je binnen de try uit de method springt, de finally niet meer uitgevoerd wordt.

Heb hier geen Visual C# express op deze pc dus ik kan het zo gauw niet controleren.

Een finally (in Java) wordt altijd uitvoerd, ongeacht of er een fout optreed of niet. Als het goed is wordt het finally block ook uitgevoerd als er een return statement staat.

[JKVA]

Dat is idd het idee van een finally. Er zijn twee uitzonderingen die misschien flauw klinken, maar het is waar, en dat zijn:
1 Bij System.exit() wordt het niet uitgevoerd
2 Bij een Error, zoals java.lang.OutOfMemoryError, waardoor het programma abrupt gestopt wordt.

Verder... altijd finally.

Overigens wil het feit dat de code in een finally block komt, niet zeggen dat deze ook totaal afgerond wordt.

Zie dit voorbeeld:

Java:

public class Question46{
    public static void main(String[] args) throws Exception{
        try{
            int i=5/(int)Math.random();
            System.out.println("i="+i);
        } catch(ArithmeticException ae) {
            throw new Exception("thrown from first catch");
        } catch(Exception e){
            throw new Exception("thrown from second catch");
        } finally {
            return;
        }
    }
}

Wat denk je dat de uitkomst is?

De uitkomst is dat er niks op de console geprint wordt. Probeer maar uit.

[Soultaker]

JKVA schreef op zondag 02 april 2006 @ 16:48:
Dat is idd het idee van een finally. Er zijn twee uitzonderingen die misschien flauw klinken, maar het is waar, en dat zijn:
1 Bij System.exit() wordt het niet uitgevoerd
2 Bij een Error, zoals java.lang.OutOfMemoryError, waardoor het programma abrupt gestopt wordt.

Verder... altijd finally.

Je kunt dus beter zeggen dat een finally block wordt uitgevoerd zodra je de bijbehorende try- en catch-blokken verlaat. In de gevallen die je noemt stopt de executie simpelweg middenin zo'n blok; logisch dat de finally dan niet wordt uitgevoerd, want er wordt helemáál geen code meer uitgevoerd. (System.exit() is dan ook een functie die je in Java moet vermijden. In C++ trouwens ook, om dezelfde reden.)

Overigens wil het feit dat de code in een finally block komt, niet zeggen dat deze ook totaal afgerond wordt.

Zie dit voorbeeld:

Java:

public class Question46{
    public static void main(String[] args) throws Exception{
        try{
            int i=5/(int)Math.random();
            System.out.println("i="+i);
        } catch(ArithmeticException ae) {
            throw new Exception("thrown from first catch");
        } catch(Exception e){
            throw new Exception("thrown from second catch");
        } finally {
            return;
        }
    }
}

Hoezo wordt de code niet 'afgerond'? Alles loopt volgens verwachting; er wordt een exception gegenereert in het try-blok, die wordt afgehandeld in het catch-blok en tenslotte (vóórdat de exception geretourneerd wordt) wordt het finally-blok uitgevoerd.

[Daspeed]

Is dat ook nog per taal afhankelijk? Ik meen dat het in .NET (C#) in ieder geval niet mogelijk was om te returnen in een finally-blok

[JKVA]

Soultaker schreef op zondag 02 april 2006 @ 17:56:
[...]

Je kunt dus beter zeggen dat een finally block wordt uitgevoerd zodra je de bijbehorende try- en catch-blokken verlaat. In de gevallen die je noemt stopt de executie simpelweg middenin zo'n blok; logisch dat de finally dan niet wordt uitgevoerd, want er wordt helemáál geen code meer uitgevoerd. (System.exit() is dan ook een functie die je in Java moet vermijden. In C++ trouwens ook, om dezelfde reden.)


[...]

Hoezo wordt de code niet 'afgerond'? Alles loopt volgens verwachting; er wordt een exception gegenereert in het try-blok, die wordt afgehandeld in het catch-blok en tenslotte (vóórdat de exception geretourneerd wordt) wordt het finally-blok uitgevoerd.

Wat ik hiermee probeer te zeggen is dat de finally niet per se compleet doorlopen hoeft te worden. In dit voorbeeldje wordt bijvoorbeeld geen exceptie opgegooid, aangezien de finally de flow onderbreekt door een return te doen.

Overigens geeft de compiler waarschuwingen als je zulke lelijke dingen doet, maar het kan wel.

[Janoz]

OlafvdSpek schreef op vrijdag 31 maart 2006 @ 20:26:
[...]

Inderdaad door de variabele scope.

[...]

Voor lokale variabelen hoef je toch niet te wachten op de garbage collector.

Wanneer jij uit je connection pool een connectie opvraagt en deze toekend aan een lokale variabele dan heeft die connection pool toch geen enkele notie meer van of deze connectie nu nog wel of nog niet binnen de scope valt of dat hij misschien wel ergens anders aan is toegekend?

[Verwijderd]

Gunp01nt schreef op zondag 02 april 2006 @ 13:08:

C#:

      try
      {
          return adapter.SelectCommand.ExecuteScalar().ToString();
      }
      finally
      {
         conn.Close()
      }

Sowieso geeft ExecuteScalar een object terug (Vergelijk met vb.net --> option explicit / option strict)
En daar roep je de ToString-functie van aan?
Ik zou hier een typecast verwachten.
En afhankelijk v.d query kan ExecuteScalar ook geen resultaat teruggeven.

[Olaf van der Spek]

Janoz schreef op zondag 02 april 2006 @ 20:36:
Wanneer jij uit je connection pool een connectie opvraagt en deze toekend aan een lokale variabele dan heeft die connection pool toch geen enkele notie meer van of deze connectie nu nog wel of nog niet binnen de scope valt of dat hij misschien wel ergens anders aan is toegekend?

Dat hangt natuurlijk van de code af. In C++ zou je de handle die je van de pool terugkrijgt moeten wrappen in een class die automatisch een reference count voor die handle bijhoudt. Dan kun je er mee doen wat je wil en als de handle uit alle scopes verdwenen is, is de reference count weer 0 en kan de pool er weer iets anders mee doen.

[Janoz]

Maar dan zul je de referenties ook bij moeten kunnen houden. Bij C is het inderdaad mogelijk om de operators te overloaden waardoor je zelf je reference counter kunt updaten, maar op wat voor manier wordt je pool op de hoogte gebracht wanneer zo'n referentie niet meer wordt gebruikt?

Ikzelf werk vooral met java. Zodra ik een object heb dat ik toeken aan b en ik doe ergens a=b dan weet dat object niet dat a naar hem wijst. Het object heeft geen enkele notie van het feit dat er nu 2 variabelen zijn die naar die ene instantie verwijzen.

[doskabouter]

EXX schreef op zaterdag 29 maart 2003 @ 11:29:
Het toppunt vind ik toch nog altijd assembly programma's die zichzelf modificeren door opcodes in het programma te wijzigen. Werd heel vroeger (toen geheugen heel krap was) wel eens gedaan, maar slecter kan het eigenlijk niet wat netjes programmeren betreft.

Heb ik vroeger ook wel een gedaan idd om memory te sparen (progje gebruikte iets van 250 bytes resident in het geheugen), maar het duurde wel erg lang voordat ik er achter kwam waarom het op een xt wel draaide, maar op een 286 niet. Uiteindelijk bleek dat de 286 al een paar instructies vooruit las, waardoor die mijn wijzigingen niet meenam....

[Olaf van der Spek]

Janoz schreef op zondag 02 april 2006 @ 22:56:
Maar dan zul je de referenties ook bij moeten kunnen houden. Bij C is het inderdaad mogelijk om de operators te overloaden waardoor je zelf je reference counter kunt updaten, maar op wat voor manier wordt je pool op de hoogte gebracht wanneer zo'n referentie niet meer wordt gebruikt?

Ikzelf werk vooral met java. Zodra ik een object heb dat ik toeken aan b en ik doe ergens a=b dan weet dat object niet dat a naar hem wijst. Het object heeft geen enkele notie van het feit dat er nu 2 variabelen zijn die naar die ene instantie verwijzen.

Als het type van A en B geen reference count kan bijhouden, moet je een wrapper gebruiken die dat wel kan, bijvoorbeeld een smart pointer, zie ook http://boost.org/libs/smart_ptr/smart_ptr.htm

[Janoz]

In java kun je een dergelijke implementatie niet afdwingen doordat je geen pointers zoals in C hebt en omdat je de operators niet kunt overloaden. Je kunt dan ook nooit garanderen dat je refcounter accuraat is.

[Olaf van der Spek]

Janoz schreef op zondag 02 april 2006 @ 23:59:
In java kun je een dergelijke implementatie niet afdwingen doordat je geen pointers zoals in C hebt en omdat je de operators niet kunt overloaden. Je kunt dan ook nooit garanderen dat je refcounter accuraat is.

Klopt, in Java heb je de garbage collector waardoor een ref counter niet nodig is. Maar die is dus niet zo strak gedefinieerd qua timing (wat ik eigenlijk niet helemaal snap).

[ Voor 35% gewijzigd door Olaf van der Spek op 03-04-2006 00:35 ]

[Robtimus]

Janoz schreef op zondag 02 april 2006 @ 22:56:
Ikzelf werk vooral met java. Zodra ik een object heb dat ik toeken aan b en ik doe ergens a=b dan weet dat object niet dat a naar hem wijst. Het object heeft geen enkele notie van het feit dat er nu 2 variabelen zijn die naar die ene instantie verwijzen.

Het object zelf niet, de VM wel. En als er geen live references meer zijn naar dat object zal het gecollect worden. Stap 1 van collecten: finalize() aanroepen. Als je dus resources wilt vrijgeven is dat the place to be.

[Not Pingu]

Verwijderd schreef op zondag 02 april 2006 @ 21:22:
[...]

Sowieso geeft ExecuteScalar een object terug (Vergelijk met vb.net --> option explicit / option strict)
En daar roep je de ToString-functie van aan?
Ik zou hier een typecast verwachten.
En afhankelijk v.d query kan ExecuteScalar ook geen resultaat teruggeven.

hmja, dus je krijgt altijd de classname van het object terug als er geen exceptions optreden tenminste.

[Janoz]

IceManX schreef op maandag 03 april 2006 @ 09:03:
[...]
Het object zelf niet, de VM wel. En als er geen live references meer zijn naar dat object zal het gecollect worden. Stap 1 van collecten: finalize() aanroepen. Als je dus resources wilt vrijgeven is dat the place to be.

Maar als je gebruik maakt van connection pooling dan zal deze nog steeds een referentie naar dat object hebben en zal de GC hem niet op gaan ruimen.

[Olaf van der Spek]

Janoz schreef op maandag 03 april 2006 @ 10:09:
Maar als je gebruik maakt van connection pooling dan zal deze nog steeds een referentie naar dat object hebben en zal de GC hem niet op gaan ruimen.

Maar als je die handle wrapped in een andere class, dan wordt de destructor van die andere class toch aangeroepen (omdat de pool die andere class zelf niet gebruikt)?
In die andere class kun je de handle dan weer teruggeven aan de pool.

[JKVA]

IceManX schreef op maandag 03 april 2006 @ 09:03:
[...]
Het object zelf niet, de VM wel. En als er geen live references meer zijn naar dat object zal het gecollect worden. Stap 1 van collecten: finalize() aanroepen. Als je dus resources wilt vrijgeven is dat the place to be.

Behalve dat je nooit belangrijke code in de finalize mag zetten. Met belangrijke code doel ik op code waarvan je zeker wil weten dat die uitgevoerd wordt. De finally finalize kan namelijk best nooit runnen, simpelweg omdat een object niet per se gecollect hoeft te worden.

Vertrouw nooit op de garbage collector. Zelfs al werkt je code prima op je windows bak, kan het best zijn dat het op een linux server niet werkt.

edit:
Ach, finally en finalize zijn toch hetzelfde.

[ Voor 6% gewijzigd door JKVA op 15-05-2006 22:14 ]

[Verwijderd]

Haal je nu niet finally en finalize door elkaar?

[Skit3000]

MAZZA schreef op zaterdag 29 maart 2003 @ 13:13:
In PHP:

Een select op de database, vervolgens de rows tellen. Dan dit aantal opslaan in een variabele $count. $count++ En daarna een INSERT query op diezelfde database om een oplopend id te krijgen met de waarde uit $count

Ik ben wel eens een DBMS tegengekomen waarbij iets als dit móest, omdat autonummering simpelweg er niet in zat... Maar dan had ik het nog opgelost met SELECT MAX(idblaat) + 1 AS newid FROM TABEL om zo te voorkomen dat als er toevallig een ID zou missen, hij twee keer dezelfde zou gebruiken.

[Janoz]

OlafvdSpek schreef op maandag 03 april 2006 @ 10:24:
[...]

Maar als je die handle wrapped in een andere class, dan wordt de destructor van die andere class toch aangeroepen (omdat de pool die andere class zelf niet gebruikt)?
In die andere class kun je de handle dan weer teruggeven aan de pool.

Goed, stel dat zou werken. Bij java is het niet zo dat objecten opgeruimt worden zodra ze out of scope verdwijnen. Ze worden gescheduled en verwijderd zodra de GC een kleer draait. Als je daarop moet wachten voordat een verbinding weer vrijgegeven wordt dan wordt dat redelijk duur.

Als je een filehandle neemt dan close je die toch ook zelf? Of laat je dat ook afhandelen door de destructors?

[Olaf van der Spek]

Janoz schreef op maandag 03 april 2006 @ 11:27:
Als je een filehandle neemt dan close je die toch ook zelf? Of laat je dat ook afhandelen door de destructors?

Dat wordt ook gedaan door een destructor.

[Xorgye]

Dat t gedaan word betekend dus nog niet dat t de mooiste manier van programmeren is

Ach, uit de tijd dat ik nog neit helemaal wist hoe programmeren werkte..

situatie:
-Ik wist dat je met QBASIC dingen kon maken
-me broertje speelde transport tycoon
-ik kon het niet uitstaan

oplossing: beveiliging van trans.exe

werkwijze:
-open met texteditor trans.exe
-doe een paar enters en voeg toe:
PRINT "GEEF JE WACHTWOORD"
INPUT $wachtwoord
IF $wachtwoord NOT "aabb" THEN EXIT
-sla op, sluit af en...

hij doet t niet meer
Ik snapte tijden lang neit waarom t nie mocht maar omdat t niet kon deed ik t ook maar niet... dat werken met teksteditors in binaire bestanden, en dan aan het begin ongecompileerde code invoegen in een bestand dat vol staat met statische referenties

[ Voor 7% gewijzigd door Xorgye op 03-04-2006 14:05 ]

[Olaf van der Spek]

Xorgye schreef op maandag 03 april 2006 @ 14:04:
Dat t gedaan word betekend dus nog niet dat t de mooiste manier van programmeren is

Maar dat is het IMO wel.
Door resource management automatisch op deze manier te doen voorkom je gewoon resource leaks, zelfs als er excepties optreden.
Waarom zou je voor memory wel automatisch management gebruiken maar het voor files en netwerk connecties handmatig doen?

[Erkens]

OlafvdSpek schreef op maandag 03 april 2006 @ 14:16:
Door resource management automatisch op deze manier te doen voorkom je gewoon resource leaks, zelfs als er excepties optreden.

als fallback bij een exception is het handig ja, maar verder is het niet een mooie constructie om te gebruiken.

Waarom zou je voor memory wel automatisch management gebruiken maar het voor files en netwerk connecties handmatig doen?

Omdat je daar niet op wilt wachten, zodra je klaar bent met je file wil je die bijvoorbeeld opgeslagen hebben -> close.

Hetzelfde als je netwerk connectie, als je klaar bent wil je niet dat de andere kant onnodig jouw connectie open heeft. Dat je memory niet vrijgeeft is jouw probleem, maar files/netwerk connections open houden is ook een probleem voor andere omdat die onnodig moeten wachten. Door zo vroeg mogelijk al de boel te sluiten kan je veel deadlocks voorkomen.

[Olaf van der Spek]

Erkens schreef op maandag 03 april 2006 @ 14:23:
Omdat je daar niet op wilt wachten, zodra je klaar bent met je file wil je die bijvoorbeeld opgeslagen hebben -> close.

Ik heb het wel over C++, waar je dus niet hoeft te wachten op een garbage collector. Handle out of scope -> auto close.

[Erkens]

OlafvdSpek schreef op maandag 03 april 2006 @ 14:25:
[...]

Ik heb het wel over C++, waar je dus niet hoeft te wachten op een garbage collector. Handle out of scope -> auto close.

Dan nog moet je wachten tot je out of scope bent
Maar vind je dat dan daadwerkelijk mooie code? Er van uit gaan dat de troep achter je opgeruimt wordt?
Overigens, als je een stuk geheugen alloceerd en daar een filepointer in duwt wordt het dus niet automatisch geclosed

[Zoijar]

Erkens schreef op maandag 03 april 2006 @ 14:55:
Maar vind je dat dan daadwerkelijk mooie code? Er van uit gaan dat de troep achter je opgeruimt wordt?

Ja, dat is mooie code Het is ook vaak de enige correcte code. Je moet er in C++ vanuit gaan dat er op elk moment een exception gegooid kan worden (tenzij je heel zeker weet dat dit niet zo is). Code als:

C++:

int handle = open();

my_stuff();
more_stuff();

close(handle);

Bevat een potentieel resource leak als een van de functies my_stuff of more_stuff een exception gooit. De "C++ way" is dus een object. Het RAII (resource aquisition is initialization) concept heet dat.

C++:

struct Guard {
Guard() {open();}
~Guard() {close();}
};

{
Guard g;
my_stuff();
more_stuff();
}

is wel exception safe.

Bijkomstigheid is nog dat als open() een exception gooit, dat met de Guard manier close() nooit wordt aangeroepen, want een niet fully constructed object wordt geen destructor van aangeroepen.

[ Voor 11% gewijzigd door Zoijar op 03-04-2006 15:28 ]

[Olaf van der Spek]

Erkens schreef op maandag 03 april 2006 @ 14:55:
Dan nog moet je wachten tot je out of scope bent

Als je echt haast hebt kun je natuurlijk altijd zelf close aanroepen.

Maar vind je dat dan daadwerkelijk mooie code? Er van uit gaan dat de troep achter je opgeruimt wordt?
Overigens, als je een stuk geheugen alloceerd en daar een filepointer in duwt wordt het dus niet automatisch geclosed

Dat is toch ook precies de bedoeling?
Je wilt dangling handles namelijk voorkomen.
Je kunt daarvoor ook een weak pointer gebruiken. De file wordt dan gesloten als er geen non-weak pointers meer zijn.

Het is toch veel eenvoudiger om een keer close() in de destructor aan te roepen dan van elke gebruiker van de class dat die zelf close() aanroept (en dan inderdaad 'troep' als finally nodig heeft)?

[ Voor 24% gewijzigd door Olaf van der Spek op 03-04-2006 15:35 ]

[kim72]

Nog iets wat goed is om te weten bij Java:

Java:

public class QuestionXX {
  public static void main(String[] args) {
    System.out.println(getResult());
  }
  private static String getResult() {
    try{
      try{
        return "exit 1";
      } finally {
        return "exit 2";
      }
    } finally {
      return "exit 3";
    }
  }
}

Het resultaat is hier dat "exit 3" wordt afgedrukt. Handig om toch even te weten!

[Michali]

Ik neem aan dat je het in dit topic plaatst om iedereen af te raden een dergelijke constructie te gebruiken?

[whoami]

Hoezo, handig om te weten ? Het staat toch duidelijk in de manual dat finally altijd uitgevoerd wordt; of er nu een exceptie gegooid wrodt of niet ?
Wel vreemd eigenlijk dat Java toelaat dat je een return statement hebt in een finally block; C# laat dat bv niet toe, en geeft een compiler error.

[-FoX-]

whoami schreef op maandag 15 mei 2006 @ 11:23:
Hoezo, handig om te weten ? Het staat toch duidelijk in de manual dat finally altijd uitgevoerd wordt; of er nu een exceptie gegooid wrodt of niet ?
Wel vreemd eigenlijk dat Java toelaat dat je een return statement hebt in een finally block; C# laat dat bv niet toe, en geeft een compiler error.

Niet altijd... vervang return "exit 1"; door System.exit(0);.. en finally wordt niet altijd uitgevoerd

[Cyphax]

Die returns voert ie dus pas uit (onder de motorkap) nadat de hele functie is doorlopen?

[Salandur]

het returnstatement in het finally block past enkel de return value aan, dus naar "exit 3".
het zou inderdaad wel prettiger zijn als de java compiler hier een error geeft, maar echt ongeldig is het niet.

[Verwijderd]

Op een avond gaan cantussen met citroenjenever. Achteraf nog wat op cafe geweest. Als ik terug op mijn kot kwam er niet beter op gevonden dan wat te gaan programmeren. Dit was hetgeen ik de volgende morgen vond:

Java:

for (int i=0;i<resultMatrix.length;i++){
    for (int j=0;j<resultMatrix[0].length;j++){
        resultMatrix[i][j]=null;
        }
}

Ik heb mooi in comment in het programma laten staan. Kwestie van elke keer als ik voorbij die klasse kom nog is goed te kunnen lachen, en kwam het onlangs dus is terug tegen. Wat ik juist van plan was die avond weet ik niet meer (ik kon me in het algemeen niet bepaald veel herinneren van die avond), maar vermoed dat ik hem wou initialiseren ofzo.

[JKVA]

-FoX- schreef op maandag 15 mei 2006 @ 11:37:
[...]

Niet altijd... vervang return "exit 1"; door System.exit(0);.. en finally wordt niet altijd uitgevoerd

Idd, of laat het geheugen lekker vollopen in je try block. Dan is er ook geen finally.

[Paul]

Cyphax schreef op maandag 15 mei 2006 @ 11:38:
Die returns voert ie dus pas uit (onder de motorkap) nadat de hele functie is doorlopen?

Niet echt. Hij voert de return meteen uit en wil dus uit de procedure springen. Een return respecteerd echter wel de try..finally-blokken. Er wordt er dus eerst gereturnd met 1. Omdat het in een try..finally-blok staat springt hij naar de finally -> return 2. Ook dit staat in een try..finally -> return 3.

Verwijderd schreef op maandag 15 mei 2006 @ 16:20:
Ik heb mooi in comment in het programma laten staan. Kwestie van elke keer als ik voorbij die klasse kom nog is goed te kunnen lachen, en kwam het onlangs dus is terug tegen. Wat ik juist van plan was die avond weet ik niet meer (ik kon me in het algemeen niet bepaald veel herinneren van die avond), maar vermoed dat ik hem wou initialiseren ofzo.

Wat is hier zo verschrikkelijk aan? Je gaat er vanuit dat de multidimensionale array vierkant is, wat als (premature) optimalisatie aangemerkt zou kunnen worden, maar als je toch weet dat je array vierkant is, waarom niet?
Ik ben niet zo bekend met Java, dus misschien staat alles default al wel op null, dus bij een initialisatie heeft het misschien niet heel veel nut, maar verder zie ik hier niet echt een wtf in?

Een collega van mij heeft wel een heel ingenieus stukje bedacht
Je hebt: 1 combobox, een dropdownlist met de volgende items: maandag dinsdag etc.
Vervolgens wil je, nadat er iets in die combobox gekozen is, weten welk dagnummer het heeft. Maandag = 0, dinsdag = 1 etc. Dat doe je met de volgende procedure:

Delphi:

function WeekdagNaarNummer(dag : string):integer;
var
  i,  uit : integer;
begin
  uit := 0;
  for i := 0 to cmbDagVDWeek.Items.Count-1 do
  begin
    if dag = cmbDagVDWeek.Items[i] then
      uit := i;
  end;
  result := uit;
end;

en dit roep je vervolgens letterlijk op 1 plaats aan, en wel met de volgende code:

Delphi:

bla := WeekdagNaarNummer(cmbDagVDWeek.Items[cmbDagVDWeek.ItemIndex]);

Ik heb er al een stuk of 4 WTF's in gevonden, maar als je er meer ziet: post ze maar

1. Die aanroep doet hetzelfde als bla := cmbDagVDWeek.ItemIndex
2. De functie is een herimplementatie van TComboBox.Items.IndexOf ofwel TStrings.IndexOf
3. Een variabele uit? Doe dat dan meteen met Result, Delphi springt niet uit de procedure zodra je iets aan Result durft toe te kennen...
4. Dit is zoeken op/met/van (hoe noem je dat ) orde N. Nu is een functie op 0.5N nog steeds N, maar zodra "uit" gevonden was kon er wel uit de loop gesprongen worden. Niet dat het op 7 items echt veel scheelt, maar toch

[ Voor 70% gewijzigd door Paul op 15-05-2006 23:07 ]

[Erkens]

JKVA schreef op maandag 15 mei 2006 @ 22:20:
Idd, of laat het geheugen lekker vollopen in je try block. Dan is er ook geen finally.

correct me if i'm wrong, maar was daar juist niet die finally voor bedoeld? dat je in dat soort situaties nog bijvoorbeeld je connecties keurig kan afsluiten etc?

[Paul]

Erkens schreef op maandag 15 mei 2006 @ 22:56:
[...]

correct me if i'm wrong, maar was daar juist niet die finally voor bedoeld? dat je in dat soort situaties nog bijvoorbeeld je connecties keurig kan afsluiten etc?

Precies. Met een EOutOfMemmoryError gaat die hele PC op zijn bek, dus dan heb je wel een groter probleem dan die databaseconnectie (die als het goed is vanzelf sluit als de TCP-verbinding wegvalt).

[Erkens]

Paul Nieuwkamp schreef op maandag 15 mei 2006 @ 23:08:
[...]
Precies. Met een EOutOfMemmoryError gaat die hele PC op zijn bek, dus dan heb je wel een groter probleem dan die databaseconnectie (die als het goed is vanzelf sluit als de TCP-verbinding wegvalt).

offtopic:
Wie heeft het over database connecties over TCP?

Maar dan nog zou die finally uitgevoerd moeten worden als je out of memory bent, of ben ik nu gek?

[Paul]

Ik ben niet echt bekend met java, en iedere keer dat ik tot dusver een OutOfMemoryError heb gehad (wat dus nog nooit met Java is gebeurd) hing de hele pc. Over connecties naar een lokale database hoef je je dan niet druk te maken, die hangt ook, vandaar mijn opmerking over de netwerkconnectie.

Of een finally daadwerkelijk wordt uitgevoerd zou ik niet weten, maar je loopt kans dat de dingen in die finally zelf ook weer een OOME gooien natuurlijk

[Olaf van der Spek]

Paul Nieuwkamp schreef op maandag 15 mei 2006 @ 23:08:
Precies. Met een EOutOfMemmoryError gaat die hele PC op zijn bek, dus dan heb je wel een groter probleem dan die databaseconnectie (die als het goed is vanzelf sluit als de TCP-verbinding wegvalt).

Gebruik je nog Windows 9x dan?

Maar volgens mij is het afsluiten van (database) verbindingen niet echt nodig als je app exit.

[Paul]

OlafvdSpek schreef op maandag 15 mei 2006 @ 23:37:
Gebruik je nog Windows 9x dan?

Ik weet niet of een Non-paged-pool empty onder OutOfMemory valt, maar dat trekt (het nuttige deel van -> dhcp, dns, MSSQL etc. RDP werkte nog wel ) je SBS2003-server wel onderuit ja

[ Voor 15% gewijzigd door Paul op 15-05-2006 23:40 ]

[JKVA]

Volgens mij valt er weinig zinnigs te zeggen over die errors en kunnen ze semi-random optreden. Het komt er wel op neer dat als je die error krijgt, heel de JVM op zijn gat ligt en hij geen code meer uitvoert, ook geen finally. Vergelijk maar met de stekker eruit trekken, dan gebeurt er ook niet veel meer.

Hoe het met connecties zit, hangt volgens mij vooral af van het type connectie en het systeem waarmee je connect.

Kortom, als die error optreedt, heeft de garbage collector al hard gewerkt om geheugen vrij te maken en is het niet gelukt waardoor je hopeloos verloren bent.

[ Voor 18% gewijzigd door JKVA op 16-05-2006 07:18 ]

[intGod]

Alarmnummer schreef op zaterdag 29 maart 2003 @ 10:55:

code:

if blaat then begin
end else begin
     doe iets.
end;

Dit is niet noodzakelijkerwijs slecht. Als je wat rondleest en ervaring opdoet zal je merken dat het de voorkeur krijgt om een positieve evaluatie in je voorwaardelijke stelling op te nemen. Soms kan het dan voorkomen dat het deel wat waar is niet bestaat.

Dus ...

[ Voor 51% gewijzigd door intGod op 16-05-2006 07:29 ]

[Verwijderd]

Als je wat rondleest en ervaring opdoet zal je merken dat het de voorkeur krijgt om een positieve evaluatie in je voorwaardelijke stelling op te nemen.

Een voorkeur die nergens op slaat. Gewoon evalueren op de beste manier. Niet uit onbegrip een methode gebruiken die vaak beter is maar soms ook niet.

[whoami]

Erkens schreef op maandag 15 mei 2006 @ 23:12:
[...]

offtopic:
Wie heeft het over database connecties over TCP?

Maar dan nog zou die finally uitgevoerd moeten worden als je out of memory bent, of ben ik nu gek?

Ik vermoed van wel, aangezien er een exceptie gegooid zal worden, en ook dan wordt de finally uitgevoerd.

[whoami]

intGod schreef op dinsdag 16 mei 2006 @ 07:29:
[...]


Dit is niet noodzakelijkerwijs slecht. Als je wat rondleest en ervaring opdoet zal je merken dat het de voorkeur krijgt om een positieve evaluatie in je voorwaardelijke stelling op te nemen. Soms kan het dan voorkomen dat het deel wat waar is niet bestaat.

Dus ...

Daar ben ik niet mee akkoord; waarom zou het beter zijn om een 'positieve' evaluatie te schrijven (wtf?) als je dan gewoon geen then hebt, en alles in de else zet ? Verwarring alom, want je zou er wel eens kunnen over lezen, dat die code in de else staat.

[Verwijderd]

Paul Nieuwkamp schreef op maandag 15 mei 2006 @ 22:51:
Een collega van mij heeft wel een heel ingenieus stukje bedacht
Je hebt: 1 combobox, een dropdownlist met de volgende items: maandag dinsdag etc.
Vervolgens wil je, nadat er iets in die combobox gekozen is, weten welk dagnummer het heeft. Maandag = 0, dinsdag = 1 etc. Dat doe je met de volgende procedure:

Delphi:

function WeekdagNaarNummer(dag : string):integer;
var
  i,  uit : integer;
begin
  uit := 0;
  for i := 0 to cmbDagVDWeek.Items.Count-1 do
  begin
    if dag = cmbDagVDWeek.Items[i] then
      uit := i;
  end;
  result := uit;
end;

en dit roep je vervolgens letterlijk op 1 plaats aan, en wel met de volgende code:

Delphi:

bla := WeekdagNaarNummer(cmbDagVDWeek.Items[cmbDagVDWeek.ItemIndex]);

Ik heb er al een stuk of 4 WTF's in gevonden, maar als je er meer ziet: post ze maar

1. Die aanroep doet hetzelfde als bla := cmbDagVDWeek.ItemIndex
2. De functie is een herimplementatie van TComboBox.Items.IndexOf ofwel TStrings.IndexOf
3. Een variabele uit? Doe dat dan meteen met Result, Delphi springt niet uit de procedure zodra je iets aan Result durft toe te kennen...
4. Dit is zoeken op/met/van (hoe noem je dat ) orde N. Nu is een functie op 0.5N nog steeds N, maar zodra "uit" gevonden was kon er wel uit de loop gesprongen worden. Niet dat het op 7 items echt veel scheelt, maar toch

Nog eentje dan:
Waarom initialiseert ie uit met waarde 0? Hij wordt (in dit geval) sowiso overgeschreven, of als we even uitgaan dat dat niet altijd kan gebeuren, dan moet je hem initialiseren met waarde -1 lijkt me (hij gebruikt toch een integer ervoor, of weet ie niet dat er ook cardinal of byte bestaat.

---

BoAC schreef op dinsdag 16 mei 2006 @ 10:14:
Dan nog beter zo als je positief wil evalueren:

code:

if blaat = false then begin
     doe iets.
end;

Dat vind ik eigenlijk wel een goede compromis.

Ik gebruik meestal het volgende:

code:

if not blaat then

Maar jouw voorbeeld is misschien toch een stukje duidelijker.

Maar als je bijvoorbeeld alleen iets wil doen als een getal niet een bepaalde waarde heeft, dan lijkt me dit nog steeds duidelijker:

code:

if getal <> 42 then

dan in de positieve vorm:

code:

if getal < 42 or getal > 42

[ Voor 16% gewijzigd door Verwijderd op 16-05-2006 11:05 ]

[BoAC]

intGod schreef op dinsdag 16 mei 2006 @ 07:29:
[...]


Dit is niet noodzakelijkerwijs slecht. Als je wat rondleest en ervaring opdoet zal je merken dat het de voorkeur krijgt om een positieve evaluatie in je voorwaardelijke stelling op te nemen. Soms kan het dan voorkomen dat het deel wat waar is niet bestaat.

Dus ...

Dan nog beter zo als je positief wil evalueren:

code:

if blaat = false then begin
     doe iets.
end;

[Paul]

Verwijderd schreef op dinsdag 16 mei 2006 @ 10:07:

Nog eentje dan:
Waarom initialiseert ie uit

Om de compiler-warning "Warning: Variable "foo" might not have been initialized" weg te werken

met waarde 0? [...] initialiseren met waarde -1 lijkt me

Omdat we liever foutievelijk een maandag opslaan dan dat wel een niet bestaande dag nemen. Natuurlijk had er ook en foutmelding gegeven kunnen worden ofzo, maar gezien de rest van de code zou die foutmelding alleen maar "te mooi maken" zijn, aldus mijn baas -> teveel tijd kosten en niets (of bijna niets) opbrengen, die foutmelding zou toch nooit weergegeven worden.

(hij gebruikt toch een integer ervoor, of weet ie niet dat er ook cardinal of byte bestaat.

Het veld in de database is ook Integer, veel meer keuzes op dat gebied biedt de database ook niet.

Daarnaast vind ik het persoonlijk een beetje overbodig om overal waar je een getal teruggeeft in een niet embedded-systeem te gaan zitten kijken signed of niet? Past het in een byte? Een word dan? terwijl je net zo snel en ten koste van een heeeeel klein beetje geheugen net zo goed een doodnormale integer kunt nemen.

Ik gebruik meestal het volgende:

code:

if not blaat then

Maar jouw voorbeeld is misschien toch een stukje duidelijker.

Er zijn talen waar je met "== false" (en "== true") uit moet kijken (C comes to mind), omdat ze geen native Boolean-type hebben en dus met dingen als 0 en alles-behalve-0 werken. Daarnaast vind ik persoonlijk een not net zo duidelijk en netter. Om een of andere reden vind ik if (foo == false) (en nog een stuk erger: if (foo == true)) erg onprofessioneel of n00b-achtig overkomen, maar ik kan er niet helemaal bij uitleggen waarom Waarschijnlijk omdat if zelf al test op true en false ofzo.

[BoAC]

Paul Nieuwkamp schreef op dinsdag 16 mei 2006 @ 19:28:
..
Om een of andere reden vind ik if (foo == false) (en nog een stuk erger: if (foo == true)) erg onprofessioneel of n00b-achtig overkomen, maar ik kan er niet helemaal bij uitleggen waarom Waarschijnlijk omdat if zelf al test op true en false ofzo.

foo == false vind ik de duidelijkheid/leesbaarheid verhogen vandaar en ik test altijd op ==false en !=false vanwege die 'C' reden

[Olaf van der Spek]

Paul Nieuwkamp schreef op dinsdag 16 mei 2006 @ 19:28:
Om de compiler-warning "Warning: Variable "foo" might not have been initialized" weg te werken

Maar waarom gebruik je niet direct result?

[ Voor 10% gewijzigd door Olaf van der Spek op 16-05-2006 19:56 ]

[Paul]

Dat is de 3e WTF in de lijst En ook die moet je initialiseren (of iig zeker weten dat je er een waarde aan toekent) anders krijg je de warning "Return value of function "Foo" might be undefined"

[Verwijderd]

JKVA schreef op dinsdag 16 mei 2006 @ 07:17:
Volgens mij valt er weinig zinnigs te zeggen over die errors en kunnen ze semi-random optreden. Het komt er wel op neer dat als je die error krijgt, heel de JVM op zijn gat ligt en hij geen code meer uitvoert, ook geen finally. Vergelijk maar met de stekker eruit trekken, dan gebeurt er ook niet veel meer.

Hoe het met connecties zit, hangt volgens mij vooral af van het type connectie en het systeem waarmee je connect.

Kortom, als die error optreedt, heeft de garbage collector al hard gewerkt om geheugen vrij te maken en is het niet gelukt waardoor je hopeloos verloren bent.

Een OutOfMemoryError is op te vangen in een try/catch blok. Als je weet waar die fout op zou kunnen treden, kun je er ook voor zorgen dat je programma niet op zijn gat gaat. Je moet er alleen voor zorgen dat heel het geheugenvretende stuk in het try blok staat. Zodra het programma daar uit knalt, kan de garbage collector weer vrolijk aan de slag om het geheugen terug te halen.

[Paul]

Maar dan is het dus niet meer zozeer een uitzondering maar een situatie waarvan je al verwacht dat hij voor kan komen. Als er 1 error is die je vrijwel nooit expliciet af gaat vangen dan is het die wel lijkt me

Zeker als je die situatie in je except op gaat lossen kun je m.i. beter (netter?) van te voren kijken of je genoeg geheugen hebt. Geheugen vrijgeven doe je in de finally als het goed is

[DaCoTa]

Paul Nieuwkamp schreef op maandag 15 mei 2006 @ 23:08:
[...]
Precies. Met een EOutOfMemmoryError gaat die hele PC op zijn bek, dus dan heb je wel een groter probleem dan die databaseconnectie (die als het goed is vanzelf sluit als de TCP-verbinding wegvalt).

Bij mij hangt alleen de JVM. Alleen wat ik wel een enorm probleem vind is dat als bij bepaalde JVM errors de JDBC verbindingen gesloten worden, Oracle denkt dat de transactie waar hij mee bezig is gecommit mag worden...

[Robtimus]

setAutoCommit(false) aan het begin van je SQL sessie helpt niet?

[RobIII]

Ik probeer net een DRM-protected filmpje af te spelen. Er wordt me gevraagd of ik een licentie op wil halen. Best, wat jij wil...

Resultaat:

Microsoft OLE DB Provider for SQL Server error '80040e2f'

INSERT statement conflicted with COLUMN FOREIGN KEY constraint 'FK_AccessLog_Sku'. The conflict occurred in database 'DMESH', table 'Sku', column 'sku_id'.

/include/licenser_data.inc

Als je dan toch DRM licenties verstrekt, en je bouwt het met wat ASP op IIS (an sich niks mis mee, ik gebruik zelf ook in 99% van de gevallen ASP en IIS) dan

• zorg je toch op z'n minst dat je geen detailed error reports verstuurt?
• rule #1 voor ASP: Noem je includes geen .inc (want die worden gewoon als plain text geserveerd: ik kan zo de broncode inzien)
• Zorg je toch voor error handling?

Ik wil dat filmpje niet eens meer afspelen. God weet wat voor braque systeem die gasten (drmnetworks.com) gebruiken. Straks word ik opgepakt door de FBI Of erger: Liggen mijn gegevens op straat voor jan en alleman om in te zien!

* RobIII huivert altijd van dit soort gevallen. "Grote jongens" die het verprutsen

Nog een side-WTF: Schattig hoe ze die emailadressen proberen te verbergen voor bots Ook handig dat de href wél gewoon de emailadressen bevat

[ Voor 23% gewijzigd door RobIII op 19-05-2006 01:41 ]

[NMe]

RobIII schreef op vrijdag 19 mei 2006 @ 01:26:
Ik wil dat filmpje niet eens meer afspelen.

Precies! Je kan je pr0n ook van andere plaatsen downloaden!

Nog een side-WTF: Schattig hoe ze die emailadressen proberen te verbergen voor bots Ook handig dat de href wél gewoon de emailadressen bevat

Dat zie ik wel vaker...je vraagt je toch af wat mensen bezielt. Sowieso lijkt het me dat spambots intussen de (at), [at], (@), [@], enz. ook wel kennen, beetje nutteloos zo.

[RobIII]

-NMe- schreef op vrijdag 19 mei 2006 @ 01:46:
Precies! Je kan je pr0n ook van andere plaatsen downloaden!

Alsof ik zou betalen voor pr0n

-NMe- schreef op vrijdag 19 mei 2006 @ 01:46:
[...]

Dat zie ik wel vaker...je vraagt je toch af wat mensen bezielt. Sowieso lijkt het me dat spambots intussen de (at), [at], (@), [@], enz. ook wel kennen, beetje nutteloos zo.

Om nog maar niet te spreken over [e-mail] (remove nospam)

[ Voor 23% gewijzigd door RobIII op 19-05-2006 01:57 ]

[Cyphax]

RobIII schreef op vrijdag 19 mei 2006 @ 01:26:
Ik probeer net een DRM-protected filmpje af te spelen. Er wordt me gevraagd of ik een licentie op wil halen. Best, wat jij wil...

Resultaat:
meh

Jammer, dat DRM. Weer een extra factor erbij waardoor het mis kan gaan.
Maarre, over dat .inc: je kunt in IIS niet instellen dat ie die parsed als asp bestanden? In Apache is dat geen probleem maar dat kan IIS toch ook wel?
In elk geval is dat iets waar je bij PHP ook voor moet uitkijken.

[ Voor 50% gewijzigd door Cyphax op 19-05-2006 09:19 ]

[gorgi_19]

Cyphax schreef op vrijdag 19 mei 2006 @ 09:18:
[...]

Jammer, dat DRM. Weer een extra factor erbij waardoor het mis kan gaan.
Maarre, over dat .inc: je kunt in IIS niet instellen dat ie die parsed als asp bestanden? In Apache is dat geen probleem maar dat kan IIS toch ook wel?
In elk geval is dat iets waar je bij PHP ook voor moet uitkijken.

Dat kan wel, maar normaliter zit je bij een hoster met een shared pakket en heb je geen toegang tot IIS.

[Erkens]

Cyphax schreef op vrijdag 19 mei 2006 @ 09:18:
[...]

Jammer, dat DRM. Weer een extra factor erbij waardoor het mis kan gaan.
Maarre, over dat .inc: je kunt in IIS niet instellen dat ie die parsed als asp bestanden? In Apache is dat geen probleem maar dat kan IIS toch ook wel?
In elk geval is dat iets waar je bij PHP ook voor moet uitkijken.

of je zorgt ervoor dat die include directory niet bereikbaar is van buitenaf

[Wim-Bart]

Een oud stukje code:

PHP:

// initialisatie
// some other stuf

$sSql= "DELETE FROM `users` WHERE `username` like '".$_GET['user']."';";
if ($oDatabase->query($sSql))
{
  // melding
}
else
{
  HandleSQLError(__FILE__,__LINE__,$sSql,$oDatabase->error);
}
//..
//..
$oDatabase->close();

Snapte maar niet dat gebruikerstabel steeds leeg was. Bleek een grapjas te zijn die de pagina aanriep met ?user=%

[ Voor 16% gewijzigd door Wim-Bart op 19-05-2006 16:27 ]

[Voutloos]

Klassiek voorbeeldje gevoelig zijn voor sql injection dus.
Als je het maar niet met deze techniek ( WTF: Injection Rejection ) hebt opgelost.

[TeeDee]

Zo, even een ontzettende trap maar ik kwam vandaag dit pareltje tegen.
Het betreft hier een recursive method om een sitemap voor Google Sitemaps te bouwen.

C#:

        private void RecMeth(int PageParentId,string PreviousUrl,SiteMapFeedGenerator gen)
        {
            string sql="select * from v_All where ParentId = " + PageParentId+" order by LanguageId";
            string conn=ConfigurationSettings.AppSettings["Connstring"].ToString();
            GenericDataAccess sqlh = new GenericDataAccess(conn,EnumProviders.SQLClient);
            IDataReader idr=sqlh.ExecDataReader(sql,CommandType.Text);
            while(idr.Read())
            {
                string prevurl=PreviousUrl+idr["PageRewrite"]+"/";
                string lang = idr["LanguageId"].ToString();
                gen.WriteItem(Baseref+lang+prevurl, DateTime.Parse(idr["chaDate"].ToString()));
                if(PageParentId==(int)idr["ParentId"])
                {
                    RecMeth((int)idr["PageId"],prevurl,gen);
                }
            }
        }

Drie keer raden waarom een database gevuld met een kleine 4000 berichten het hier behoorlijk zwaar krijgt.

spoiler:

idr.Close() en idr.Dispose() missen, dus je krijgt geneste datareaders +/- 4000 in totaal welke een select * op een database uitvoeren.

[Not Pingu]

Om nog maar te zwijgen van het feit dat het omzetten van tabulaire data naar hierarchisch typisch iets is dat je aan applicatiezijde doet door het hele zwikkie data ineens op te halen en niet door voor elke node opnieuw naar de database te gaan.

[ikke007]

In code op mijn werk aangetroffen:

Delphi:

try
  VerwerkResultaten();
except
  ShowMessage('Resultaten Succesvol verwerkt');
end;

en ook dingen zoals:

Delphi:

  MessageDlg('Wilt u verwerken',mtWarning, mbYesNoCancel, 0);

wtf waarom doe je dan een yes/no/cancel indien het geen fluit uitmaakt

[ Voor 2% gewijzigd door ikke007 op 26-10-2006 01:44 . Reden: code tags aangepast ]

[Paul C]

Ik heb pas dit gemaakt, ik moet het nog ff herschrijven, want zo kan het natuurlijk niet:

PHP:

for($j=1; $j<$i; $j++) {
    if($artistinfo = getartistinfo($artistlist[$j]['name'])) {
        if($artistinfo['update'] < $timeoutthreshold) {
            updatesimilar($artistinfo['id'], $artistinfo['name']);
        }
        $artistlist[$j]['id'] = $artistinfo['id'];
    }
    else {
        insertartist($artistlist[$j]['name']);
        $j--;
    }
}

[TeeDee]

pcmadman schreef op donderdag 26 oktober 2006 @ 02:18:
Ik heb pas dit gemaakt, ik moet het nog ff herschrijven, want zo kan het natuurlijk niet:

PHP:

for($j=1; $j<$i; $j++) {
    if($artistinfo = getartistinfo($artistlist[$j]['name'])) {
        if($artistinfo['update'] < $timeoutthreshold) {
            updatesimilar($artistinfo['id'], $artistinfo['name']);
        }
        $artistlist[$j]['id'] = $artistinfo['id'];
    }
    else {
        insertartist($artistlist[$j]['name']);
        $j--;
    }
}

Als je er nu ook bijzet wat er fout is.... Ik gok zelf het j-- verhaal.

Not Pingu schreef op woensdag 25 oktober 2006 @ 22:03:
Om nog maar te zwijgen van het feit dat het omzetten van tabulaire data naar hierarchisch typisch iets is dat je aan applicatiezijde doet door het hele zwikkie data ineens op te halen en niet door voor elke node opnieuw naar de database te gaan.

Eens. Eén grote Datatable bijvoorbeeld. Nu zou het e.e.a. nog met Connectionpooling gecached kunnen worden, maar dit is duidelijk niet the way to go.

Janoz schreef op donderdag 26 oktober 2006 @ 09:39:
[...]


Ik gok eerder op het doorwerken van de hele lijst en elke keer weer de artiest ophalen. Vermoedelijk betekent die aanroep elke keer weer een nieuwe query op de database.

O, getartistinfo[] bedoel je?

[ Voor 12% gewijzigd door TeeDee op 26-10-2006 10:15 ]

[Janoz]

TeeDee schreef op donderdag 26 oktober 2006 @ 09:10:
[...]

Als je er nu ook bijzet wat er fout is.... Ik gok zelf het j-- verhaal.

Ik gok eerder op het doorwerken van de hele lijst en elke keer weer de artiest ophalen. Vermoedelijk betekent die aanroep elke keer weer een nieuwe query op de database.

[miniBSD]

$artistinfo = getartistinfo($artistlist[$j]['name'])

dit is de WTF. Het had moeten zijn:

$artistinfo == getartistinfo($artistlist[$j]['name'])

[LuCarD]

miniBSD schreef op donderdag 26 oktober 2006 @ 13:26:
$artistinfo = getartistinfo($artistlist[$j]['name'])

dit is de WTF. Het had moeten zijn:

$artistinfo == getartistinfo($artistlist[$j]['name'])

Onwaarschijnlijk.

getartistinfo geeft waarschijnlijk false terug als hij niet gevonden word. En dan gaat de if statement naar de else clause toe.

[InZane]

PHP:

exec("rm -f /bla/bla/".$var);

Unlink was ook goed geweest hoor.

[johnwoo]

InZane schreef op donderdag 26 oktober 2006 @ 14:17:

PHP:

exec("rm -f /bla/bla/".$var);

Unlink was ook goed geweest hoor.

Ik hoop dat $var nog wel eerst gecheckt werd? Ook zo lullig als je de pagina aanroept met ?var=../../*

[TeeDee]

johnwoo schreef op donderdag 26 oktober 2006 @ 15:05:
[...]

Ik hoop dat $var nog wel eerst gecheckt werd? Ook zo lullig als je de pagina aanroept met ?var=../../*

offtopic:
hoe zit het eigenlijk met de verdere ontwikkeling van winbar?

[Paul C]

miniBSD schreef op donderdag 26 oktober 2006 @ 13:26:
$artistinfo = getartistinfo($artistlist[$j]['name'])

dit is de WTF. Het had moeten zijn:

$artistinfo == getartistinfo($artistlist[$j]['name'])

Nee, dat is goed, want die functie returned FALSE als de artiest niet uit de database kan worden gehaald (hij bestaat niet) en anders een array met artiest informatie die even later gebruik.

Het lelijke is die $j--; die ik gebruik om terug te komen te komen bij de getartistinfo();
Als die insertartist(); namelijk failed, dan krijg je een infinite loop en dat is vanwege verschillende redenen best mogelijk.

[TeeDee]

pcmadman schreef op donderdag 26 oktober 2006 @ 17:53:
[...]
Het lelijke is die $j--;

Wat win ik?

Als die insertartist(); namelijk failed, dan krijg je een infinite loop en dat is vanwege verschillende redenen best mogelijk.

Waarom gooi je dan geen error? Lijkt me niet echt normaal behaviour om het op deze manier te doen.

[Verwijderd]

wat ik een tijd geleden op mn werk had gevonden was iets als dit

Visual Basic:

Dim naam as String
naam = inputbox("geef je naam")

if naam = "" then
msgbox "geen naam opgegeven"
naam = inputbox("geef je naam")
end if

if naam = "" then
msgbox "geen naam opgegeven"
naam = inputbox("geef je naam")
end if

zeker nooit van een while-lus gehoord

[EdwinG]

Nadenken over de structuur van een database is blijkbaar vrij lastig.
Gevonden in de database van een administratie programma

code:

  `CONTACTPERSOON_ID` int(11) NOT NULL auto_increment,
  `LAND_ID` int(11) NOT NULL default '0',
  `GESLACHT_ID` int(11) NOT NULL default '0',
  `VOORNAAM` varchar(255) default NULL,
  `TUSSENVOEGSEL` varchar(255) default NULL,
  `ACHTERNAAM` varchar(255) default NULL,
  `ADRES` varchar(255) default NULL,
  `POSTCODE` varchar(255) default NULL,
  `POSTBUS` varchar(255) default NULL,
  `POSTADRES` varchar(255) default NULL,
  `TELEFOONNUMMER` varchar(255) default NULL,
  `MOBIELNUMMER` varchar(255) default NULL,
  `FAXNUMMER` varchar(255) default NULL,
  `EMAILADRES` varchar(255) default NULL,
  `WOONPLAATS` varchar(255) default NULL,

Beetje lange postcodes als je het mij vraagt.

[Janoz]

Daarnaast, verwacht de ontwikkelaar van die DB dat we binnenkort een derde geslacht erbij zullen krijgen?

[LuCarD]

Janoz schreef op vrijdag 27 oktober 2006 @ 10:44:
Daarnaast, verwacht de ontwikkelaar van die DB dat we binnenkort een derde geslacht erbij zullen krijgen?

Eunuch?

[elTigro]

Verwijderd schreef op vrijdag 27 oktober 2006 @ 10:18:
wat ik een tijd geleden op mn werk had gevonden was iets als dit

Visual Basic:

Dim naam as String
naam = inputbox("geef je naam")

if naam = "" then
msgbox "geen naam opgegeven"
naam = inputbox("geef je naam")
end if

if naam = "" then
msgbox "geen naam opgegeven"
naam = inputbox("geef je naam")
end if

zeker nooit van een while-lus gehoord

Ik vind hem wel mooi eigenlijk.
Je hebt 3 x de kans je naam op te geven, doe je het niet, ja dan is het je eigen schuld hoor

[leuk_he]

Janoz schreef op vrijdag 27 oktober 2006 @ 10:44:
Daarnaast, verwacht de ontwikkelaar van die DB dat we binnenkort een derde geslacht erbij zullen krijgen?

de gba kent 4 waarden voor geslacht:
http://www.gba.nl/downloa...f%20validiteit%20LO40.pdf

Indien 'Onbekend': 0
1 man
2 vrouw
3 vastgesteld onbekend

en ooit wel eens nagedacht hoe groot buitenlandse postcodes zouden kunnen zijn.

[NMe]

Goed, we zitten haast aan de 1000 replies. Wie opent even een nieuw topic?

[EdwinG]

* EdwinG bied zich aan