Prev: Application Icon
Next: VO on a stick
From: Ginny Caughey on 20 Oct 2009 10:35 Hi Erik, Looks fine to me. Maybe Meinhard meant something else? -- Ginny Caughey www.wasteworks.com "E�!k \/!sser" <nospam(a)nospam.com> wrote in message news:7k5vojF37ibi7U1(a)mid.individual.net... > Oops, code should be like this: > > Erik > > IF SELF:SetValueToVar( 1001 ) > .. do something > ENDIF > > METHOD SetValueToVar( iSuggest AS INT ) AS LOGIC PASCAL CLASS SAMPLE1 > LOCAL lReturn AS LOGIC > lReturn := FALSE > IF iSuggest > 20 .AND. iSuggest < 890 > SELF:_SomeClassVar := iSuggest > lReturn := TRUE > ENDIF > RETURN lReturn >
From: Meinhard Schnoor-Matriciani on 20 Oct 2009 11:08 Erik, It's more a question of software design and coding conventions in general. Your code has a the big disadvantage that you assume that the consumer ( even if that's only you ) checks the result for success, but what happens he he/she does not ? Raising an exception is way better, because then you force to handle this exception and don't make any assumtions about the correct way about consuming your component. Regards Meinhard "E�!k \/!sser" <nospam(a)nospam.com> schrieb im Newsbeitrag news:7k5vb1F370v1sU1(a)mid.individual.net... > Hi Meinhard, > >>> That way the method can return the validation result. >> >> and that's definitely a bad approach ! > > Thanks for sharing your opinion, but could you explain what makes you > think so ? > Let me write a little sample, what is bad (IYO) in this approach? > > regards, > > Erik > > IF SELF:SetValueToVar( 1001 ) > .. do something > ENDIF > > METHOD SetValueToVar( iSuggest AS INT ) AS LOGIC PASCAL CLASS SAMPLE1 > LOCAL lReturn AS LOGIC > lReturn := TRUE > IF iSuggest > 20 .AND. iSuggest < 890 > SELF:_SomeClassVar := iSuggest > lReturn := FALSE > ENDIF > RETURN lReturn > > > > > >
From: E®!k /!sser on 20 Oct 2009 13:03 Meinhard, The discussion between Geoff and me was about using 'computational logic ' inside an access or assign. I prefer to do the 'computational logic' in a method. If it is important to notify the user about an value out of range (or whatever) ofcourse you should raise an exception. regards, Erik The sample was ment to show the benifit of using a method in stead of an assign when you want to do what Geoff called earlier "Meinhard Schnoor-Matriciani" <meinhard(a)appfact.de> schreef in bericht news:4addd3b7$1(a)news.arcor-ip.de... > Erik, > > It's more a question of software design and coding conventions in general. > Your code has a the big disadvantage that you assume that the consumer ( > even if that's only you ) checks the result for success, but what happens > he he/she does not ? Raising an exception is way better, because then you > force to handle this exception and don't make any assumtions about the > correct way about consuming your component. > > Regards > Meinhard > > "E�!k \/!sser" <nospam(a)nospam.com> schrieb im Newsbeitrag > news:7k5vb1F370v1sU1(a)mid.individual.net... >> Hi Meinhard, >> >>>> That way the method can return the validation result. >>> >>> and that's definitely a bad approach ! >> >> Thanks for sharing your opinion, but could you explain what makes you >> think so ? >> Let me write a little sample, what is bad (IYO) in this approach? >> >> regards, >> >> Erik >> >> IF SELF:SetValueToVar( 1001 ) >> .. do something >> ENDIF >> >> METHOD SetValueToVar( iSuggest AS INT ) AS LOGIC PASCAL CLASS SAMPLE1 >> LOCAL lReturn AS LOGIC >> lReturn := TRUE >> IF iSuggest > 20 .AND. iSuggest < 890 >> SELF:_SomeClassVar := iSuggest >> lReturn := FALSE >> ENDIF >> RETURN lReturn >> >> >> >> >> >> >
From: Geoff Schaller on 25 Oct 2009 17:46
Meinhard. No it is not better. That kind of approach is really best suited to event management and third party processes (for example an email class, a server class, a connection class, or hardware related things) where an unrecoverable error occurs. Look at Robert's VO2Ado classes as a good example. Definitely not suited for business logic implementations. It introduces way too much overhead and way too much coding complexity. What Erik suggests is correct. The method should usually know whether or not it succeeded and tell the calling code that with its result. The method will have set status flags and messages of course and the job's done. To now execute an exception is just crazy because you could now bypass important execution logic. An exception in generally an unrecoverable error in code execution. Success/failure can arise from correct code execution. And let's face it. VO is basically built on success messages. Just look at the RDD and Window classes for evidence. Geoff "Meinhard Schnoor-Matriciani" <meinhard(a)appfact.de> wrote in message news:4addd3b7$1(a)news.arcor-ip.de: > Erik, > > It's more a question of software design and coding conventions in general. > Your code has a the big disadvantage that you assume that the consumer ( > even if that's only you ) checks the result for success, but what happens he > he/she does not ? Raising an exception is way better, because then you force > to handle this exception and don't make any assumtions about the correct way > about consuming your component. > > Regards > Meinhard > > "ER!k \/!sser" <nospam(a)nospam.com> schrieb im Newsbeitrag > news:7k5vb1F370v1sU1(a)mid.individual.net... > > > Hi Meinhard, > > > > >>> That way the method can return the validation result. > >> > > >> and that's definitely a bad approach ! > > > > > Thanks for sharing your opinion, but could you explain what makes you > > think so ? > > Let me write a little sample, what is bad (IYO) in this approach? > > > > regards, > > > > Erik > > > > IF SELF:SetValueToVar( 1001 ) > > .. do something > > ENDIF > > > > METHOD SetValueToVar( iSuggest AS INT ) AS LOGIC PASCAL CLASS SAMPLE1 > > LOCAL lReturn AS LOGIC > > lReturn := TRUE > > IF iSuggest > 20 .AND. iSuggest < 890 > > SELF:_SomeClassVar := iSuggest > > lReturn := FALSE > > ENDIF > > RETURN lReturn > > > > > > > > > > > > |