From: Ginny Caughey on
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
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
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
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
> >
> >
> >
> >
> >
> >

First  |  Prev  | 
Pages: 1 2 3 4 5 6
Prev: Application Icon
Next: VO on a stick