Thanks Bernardo.

 

Seems your suggestion creates a Protected Block which I understand.  I will 
read the document some more a necessary.  Thank you for taking time to respond.

 

From: Bernardo Ezequiel Contreras <vonbecm...@gmail.com>
Reply to: Any question about pharo is welcome <pharo-users@lists.pharo.org>
Date: Wednesday, 2 March 2022 at 14:19
To: Any question about pharo is welcome <pharo-users@lists.pharo.org>
Subject: [Pharo-users] Re: ByteString asDate

 

see chapter 13 in

http://files.pharo.org/books-pdfs/deep-into-pharo/2013-DeepIntoPharo-EN.pdf

 

it's a chapter dedicated to exceptions. the #on:do: message is in section 13.4. 

 

regarding the asDate message,  i really don't know. you need a kind of 
validator.

 

sorry, if i'm not much help. 

 

On Wed, Mar 2, 2022 at 7:35 AM Robert Briggs via Pharo-users 
<pharo-users@lists.pharo.org> wrote:

Thanks Bernardo

 

That construct works as required, however I’m not sure what the semantic 
difference is to my original.  I seems counterintuitive.  Could you expand on 
what is going on for my benefit (if you have time).

Again thanks.

 

Also do you have a view on my description of the asDate result, and whether it 
should self-validate the receiver and raise an exception?

 

Regards

R

 

From: Bernardo Ezequiel Contreras <vonbecm...@gmail.com>
Reply to: Any question about pharo is welcome <pharo-users@lists.pharo.org>
Date: Tuesday, 1 March 2022 at 15:05
To: Any question about pharo is welcome <pharo-users@lists.pharo.org>
Subject: [Pharo-users] Re: ByteString asDate

 

try to send the #on:do: message  to a block. try this

 

^ [ (Date readFrom: self pattern: ‘dd/mm/yyyy’). 

     true ]  on: DateError do: [ false].

 

 

 

On Tue, Mar 1, 2022 at 11:52 AM Robert Briggs via Pharo-users 
<pharo-users@lists.pharo.org> wrote:

I may be being stupid but the current Date Class does not appear to protect 
itself against a ByteString that is not in valid date format, e.g. by raising 
an Error.

 

e.g. the code  ‘ABC’ asDate opens the Debugger on #isLetter was sent to nil 
because it appears to expect more letters after $C but the peek returns nil 
instead.

This seems to me to require a more defensive programming approach.

 

I would like to validate a user input as a valid date in a number of different 
formats before converting it to a Date and storing it in my model.

 

I’ve tried using the Date parser, e.g.

 

Date readFrom: '04/02/2013' readStream pattern: 'dd/mm/yyyy'.

 

 

This is fine for simply parsing a valid string but rates a DateError if it 
doesn’t match the .  So entering ‘04/13/2013’ cleverly raises ‘DateError: There 
is no 13th month’.

 

My thought was I could use this to return a simple true/false result in a 
ByteString extension in my application for example as follows:

 

ByteString >> isValdiDate

 

(Date readFrom: self pattern: ‘dd/mm/yyyy’) on: DateError do: [^ false].

^ true

 

However this doesn’t intercept the DateError which is simply reported in the 
Debugger as before.   This may be my lack of uncderstaning of the Exception 
handling in Pharo.

 

Any and all thoughts welcome.

 

R

 

 

 

 

 


 

-- 

Bernardo E.C.

 

Sent from a cheap desktop computer in South America.


 

-- 

Bernardo E.C.

 

Sent from a cheap desktop computer in South America.

Reply via email to