Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 16 to 30 of 40

Thread: Gebruik van Onvalidate

  1. #16
    Delphi & OO in Vlaanderen SamWitse's Avatar
    Join Date
    Sep 2007
    Location
    Brussel
    Posts
    833
    Ik volg je, en eerlijk heb ik eigen exception types enkel gemaakt om ook een foutnummer terug te kunnen geven.

    Maar in mijn databasevalidatie kan ik zeggen

    delphi Code:
    1. var
    2.   DatumIsZinnig: boolean ;
    3. begin
    4.  
    5. if assigned (DoVraagOfDatumZinnigIs) then
    6.   DoVraagOfDatumZinnigIs (DatumIsZinnig)
    7. else  
    8.   DatumIsZinnig := true ;
    9. if DatumIsZinnig then
    10.   Post;
    11.  
    12. end ;

    Dit is een manier om met een event te vragen aan de GUI of de datum wel zinnig is. De GUI beslist dan of ze de vraag doorspeelt aan de user dmv een dialog, of zélf beslist of de datum al dan niet zinvol is.
    Aan jou om te beslissen om dit wel of niet te implementeren door wel of niet de event te schrijven.

    Met exceptions krijg je gewild of ongewild de exception tegen je hoofd geslingerd en moet je ze maar afvangen als je ze niet aan de user wil tonen.

    Exceptions zijn voor mij harde uitzonderingen waar het helemaal fout dreigt te gaan, terwijl events ook gewoon waarschuwingen of doodnormale meldingen of vragen zijn.
    Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration.

    Sam Witse.
    Delphi & OO in Vlaanderen

  2. #17
    Klopt. Een vraag stellen doe je niet via een exception. Dat is uitgesloten, al is het maar omdat de exception niet meer terugkeert naar de plaats waarvandaan je 'm aanriep.

    Misschien komt het omdat ik dit soort situaties niet vaak voor m'n kiezen heb gekregen. In de praktijk zie ik het heel zwart-wit. Invoer is goed of invoer is fout. Is ie fout, dan wil ik dat aan de gebruiker presenteren (message box, log file, op wat voor manier dan ook). Een exception is daar een middel voor, al kan het ook op andere manieren.

    Als je een vraag wilt stellen, zoals jij, dan is een event om een vraag te laten zien op het eerste gezicht een goede oplossing. Toch kriebelt er wel iets, en ik denk dat dat dit is:

    Je database (of je tussenlaag) krijgt een waarde voor z'n kiezen. Nu kunnen er twee dingen aan de hand zijn:

    1. De waarde komt vanuit de programmatuur. In dat geval wil je het event niet afvuren, want dan krijg je gebruiker ineens de vraag om een willekeurig jaar te valideren, terwijl hij misschien niet eens weet waar het vandaan komt of wat het voorstelt.

    2. De gebruiker heeft het zelf ingetypt in de GUI. Dan is de vraag ook raar. De GUI geeft een waarde aan de database, en die vraagt in feite 'weet je het zeker'? Waarom zou de GUI erop vertrouwen dat de database die vraag stelt? Als de GUI vindt dat de gebruiker een extra bevestiging moet geven, dan zou die dat moeten doen voordat de waarde überhaupt wordt doorgegeven aan de database.

    Jij rekent waarschijnlijk op de tweede situatie en hebt misschien niet eens aan de eerste gedacht. Maar het komt op mij over als een work-around voor het lastig in kunnen haken op het moment dat een TDBEdit-achtige z'n data doorgeeft aan z'n dataset. Als dat inderdaad moelijk is (en dat is het volgens mij), dan is het op zich een prima work-around, maar qua structuur verre van ideaal.
    Last edited by GolezTrol; 17-Jan-13 at 18:16.
    1+1=b

  3. #18
    Silly member NGLN's Avatar
    Join Date
    Aug 2004
    Location
    Werkendam
    Posts
    5,133
    Sam, je beschrijft precies het gevoel wat de meeste (beginners) denk ik hebben: exceptions zijn echt héél erg verschikkelijke dingen die je ten alle tijde dient te voorkomen. Maar op datzelfde moment herinner ik mij posts, topics en gehele artikelen over het nut van exceptions. Exceptions hoeven niet kwaadaardig te zijn.
    (Sender as TNLDUser).Signature := 'Groeten van Albert';

  4. #19
    Delphi & OO in Vlaanderen SamWitse's Avatar
    Join Date
    Sep 2007
    Location
    Brussel
    Posts
    833
    De vraag is: moet de GUI de waarde van de geboortedatum checken bij elk van de mogelijke gevallen waarin een record gepost kan worden, of laat je de database vlak voor de post een vraag aan de GUI stellen?

    Yep, het kan zijn dat je programmatuur een Post uitvoert waar je het niet verwacht, en dat de gebruiker plots een vraag krijgt om de geboortedatum te bevestigen, waar de gebruiker compleet uit de lucht komt te vallen.
    Maar, zo ben je zeker dat de vraag er enkel en alleen komt als hij nodig is. Ik heb al vaak in programma's vastgezeten omdat de GUI van mij een geldige gebroortedatum eiste, terwijl ik wou cancellen! Het andere geval kan ook: GUI vergeet in bepaalde gevallen de confirmatie van de gebruiker.
    Ik weet niet welke van beide oplossingen goeder is. Een work-around zijn ze zeker niet.

    Ik kom uit de kast: ik vind exceptions nog steeds dingen die het onverwachte signaleren, en je nog nét de kans geven een brandblusser te halen.
    Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration.

    Sam Witse.
    Delphi & OO in Vlaanderen

  5. #20
    Quote Originally Posted by SamWitse View Post
    De vraag is: moet de GUI de waarde van de geboortedatum checken bij elk van de mogelijke gevallen waarin een record gepost kan worden, of laat je de database vlak voor de post een vraag aan de GUI stellen?
    Ik zou de vraag helemaal niet stellen. Datum ongeldig? Dan niet toelaten. Datum wel geldig? Dan toelaten. Mocht je toch iets willen bevestigen, dan kun je inderdaad op de plaats waar dat gebeurt de vraag stellen voor het posten. Je moet toch ook je GUI aanpassen, zodat deze reageert op het event. Dat kan net zo goed misgaan. Of wil je een centrale event handler maken? Hoe weet die dan de context waarin de datum is ingevuld?

    En daarbij, op hoeveel plaatsen in je programma pas je zo'n datum nou daadwerkelijk aan?

    Quote Originally Posted by SamWitse View Post
    Yep, het kan zijn dat je programmatuur een Post uitvoert waar je het niet verwacht, en dat de gebruiker plots een vraag krijgt om de geboortedatum te bevestigen, waar de gebruiker compleet uit de lucht komt te vallen.
    Maar, zo ben je zeker dat de vraag er enkel en alleen komt als hij nodig is.
    Juist niet. De vraag is een respons op een event dat aangeroepen wordt bij elke data-wijziging. Ook softwarematige toegang tot de databaselaag leveren (onverwacht) die melding. Bovendien: als dat in een post gebeurt, dan is de kans aanwezig dat je ook in een openstaande transactie bezig bent. Als je in die situatie een dialoog gaat tonen, kan dat een serieuze block in je database opleveren, met het onderuitgaan van je hele bedrijfsproces tot gevolg. Begin je eenmaal met opslaan, doe dan geen gebruikersinteractie meer. Dat is ook een verschil met exceptions. Die loodsen je eerst door je foutafhandeling heen en worden daarna pas (optioneel) aan de gebruiker getoond.

    Nou is het eerlijkheidhalve wel zo dat OnValidate al aangeroepen wordt zodra je de waarde in het veld zet, dus meestal ben je veilig. Maar dat sluit niet uit dat het ook op een tijdkritisch moment kan gebeuren, met mogelijk ernstige gevolgen.

    Quote Originally Posted by SamWitse View Post
    Ik heb al vaak in programma's vastgezeten omdat de GUI van mij een geldige gebroortedatum eiste, terwijl ik wou cancellen!
    Dat is dan gewoon een slecht programma. Staat hier verder los van.
    Quote Originally Posted by SamWitse View Post
    Het andere geval kan ook: GUI vergeet in bepaalde gevallen de confirmatie van de gebruiker.
    De datalaag is altijd de plaats waarin de echt ongeldige waarden afgevangen worden.

    Volgens mij was dat ook de insteek van de vraag. Bevestiging vragen is sowieso een andere situatie, waarin exceptions sowieso geen oplossing zijn. Ik stel daarin alleen het event-model ter discussie.

    Quote Originally Posted by SamWitse View Post
    Ik kom uit de kast: ik vind exceptions nog steeds dingen die het onverwachte signaleren, en je nog nét de kans geven een brandblusser te halen.
    Mijn database-laag is heel naïef. Die vindt het onverwacht als iemand probeert er ongeldige waarden in te stoppen.
    Last edited by GolezTrol; 17-Jan-13 at 20:49.
    1+1=b

  6. #21
    Reader
    Join Date
    May 2002
    Location
    Holland
    Posts
    3,382
    Ik lig al weer ver achter maar ok... hier nog een keer de zip
    Attached Files Attached Files

  7. #22
    Ik denk dat er uiteindelijk altijd een exception moet komen. Een factuur zonder factuurdatum is nou eenmaal fout, die mag nooit worden opgeslagen. De business laag weet niet of er een UI is en of die UI dichtbij is, of aan de andere kant van de wereld.

    Als je de UI vragen laat stellen als: "mag ik een factuur opslaan met deze datum?" vind ik dat overkill. Ik zou liever zeggen: "wil je deze factuur opslaan, en als het niet goed is hoor ik het wel." Dat hoor ik het wel kan inderdaad ook via een event, maar wat als dat event niet wordt afgevangen? De gebruiker druk op OK, zijn scherm wordt gesloten en hij gaat er vanuit dat de factuur wordt betaalt. Maar hij is helemaal niet opgeslagen, er was geen datum ingevuld.

    Als je dus vergeet het event af te vangen heb je een groot probleem. Als je vergeet de exception af te vangen is je probleem een stuk minder groot. De gebruiker krijgt in plaats van een vriendelijke melding een fout, maar hij weet in ieder geval dat de factuur niet is opgeslagen.

    Ik sta dus aan de kant van de exceptions. "Kan niet opslaan want er is geen database" is een exception, "Kan niet opslaan want er is geen factuurdatum" ook. Alleen is die eerste van het type EEndOfTheWorld en die twee van het type EFriendlyMessage.
    Marcel

  8. #23
    Reader
    Join Date
    May 2002
    Location
    Holland
    Posts
    3,382
    Tja... lastige materie.

    En de melding "list index out of range" dan?
    Het lijkt me dat die nooit mag voorkomen. En toch is het een exception.
    Daar zeg je ook niet: ik probeer maar wat uit die TList te halen en als het niet lukt horen we het wel.

    Database fouten leveren ook volkomen onleesbare exceptions voor een gebruiker. In je browser zie je ook weleens: sql xy error. Ontoelaatbaar toch?
    Als je een database in Parijs hebt moet er - mijns insziens - zoveel mogelijk informatie beschikbaar zijn aan de andere kant om exceptions in Amsterdam te voorkomen. Je weet toch ook de tabelnamen en veldnamen en zo?

    Ik sta aan de kant van de gebruiker: nooit en te nimmer een exception of: ten koste van veel proberen te voorkomen. En dan daarna nog: alle mogelijke moeite exceptions leesbaar te maken.

  9. #24
    Oh, maar ik zeg ook niet dat je die exception ook als zodanig aan de gebruiker moet tonen. Dat bedoelde ik met het verschil tussen de ene en de andere exception. Wat je kunt afvangen vang je af, met een nette melding (geen foutmelding dus!) en juiste reactie van de userinterface.

    De EEndOfTheWorld zul je niet afvangen, dat zal uiteindelijk tot een melding naar de gebruiker leiden. Dat zou je nog algemeen kunnen afvangen met een "Er ging iets heel erg mis" melding, als je maar zorgt dat de echte melding met alle benodigde informatie dan al in je mailbox zit.
    Marcel

  10. #25
    Reader
    Join Date
    May 2002
    Location
    Holland
    Posts
    3,382
    Mee eens.

  11. #26
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,747
    Maar nu hebben het toch over twee soorten exceptions, toch? Die van de GUI en van data.
    Als ik kijk naar een javascript met wat invoervelden kan ik ook een validatie uitvoeren. Dan kan ik ook een invoerveld rood maken om aan te geven dat hier iets fout gaat. Om telkens een popup te tonen, wordt voor de gebruiker 'een hel op aarde'. Nu is de verwerking van data en invoer van een javascript niet gescheiden zoals je dat in Delphi kan doen, maar zo'n soort validatie gebeurt wel. Lijkt mij dat je met een foutmelding via try..except een event in de GUI-form moet afschieten om te tonen wat er gebeurt (edit.color wordt rood of e.d.)

  12. #27
    Maar wie zegt er dat je een popup moet tonen? Een exception afvangen en een control rood kleuren aan de hand van die exception kan toch ook?

    Een exception is een fout, niet de popup.
    Marcel

  13. #28
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,747
    Maar exceptions zijn toch foutafhandelingen, die alleen een dialog presenteren wat jij of de debugger hebt opgegeven?

  14. #29
    Nee, een exception is een object van het type Exception. Het raisen van een exception leidt tot het zoeken naar een try/except structuur of een OnException event. In dat stuk code wordt de exception afgehandeld, dat kan inderdaad met een dialoog maar er zijn vel meer oplossingen.
    Marcel

  15. #30
    Reader
    Join Date
    May 2002
    Location
    Holland
    Posts
    3,382
    @JKuiper: Wat bedoel je??? Exceptions zijn heel wat anders/meer dan dat

Page 2 of 3 FirstFirst 1 2 3 LastLast

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •