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
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.
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 <vonbecmann@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.
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 <vonbecmann@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.
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 <vonbecmann@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 <vonbecmann@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.
Hi Guys, I'm reading a text file which is supposed to be ASCII encoded. This file contains a list of filepaths and was created by a Python program. Well, it turns-out that file names on Windows can contain illegal UTF-8 characters. This causes ZnUTF8Encoder to signal 'Illegal leading byte for utf-8 encoding' and crash the program. I would like to handle this situation more elegantly, is there a more appropriate code-page to use for the Windows filesystem? Craig
Hi Craig,
On 3 Mar 2022, at 23:15, craig <craig@hivemind.net> wrote:
Hi Guys,
I'm reading a text file which is supposed to be ASCII encoded. This file contains a list of filepaths and was created by a Python program.
Well, it turns-out that file names on Windows can contain illegal UTF-8 characters. This causes ZnUTF8Encoder to signal 'Illegal leading byte for utf-8 encoding' and crash the program.
I would like to handle this situation more elegantly, is there a more appropriate code-page to use for the Windows filesystem?
<4b5aa143.png>
Craig
We support more than 80 different character encoders. Of course, you should first know what encoder is being used, after that, it is easy to use a different encoder. Consider: '/tmp/foo.txt' asFileReference readStreamEncoded: #utf8 do: [ :in | in upToEnd ]. '/tmp/foo.txt' asFileReference readStreamEncoded: #windows1252 do: [ :in | in upToEnd ]. '/tmp/foo.txt' asFileReference readStreamEncoded: #latin1 do: [ :in | in upToEnd ]. ZnCharacterEncoder knownEncodingIdentifiers. #windows1252 asZnCharacterEncoder. If you could post a small example of your file, I could try to help. It will probably be #windows1252 or #latin1. HTH, Sven
Hi Sven, Thanks for the answer. #windows1252 did the trick. Thanks again. Craig
We support more than 80 different character encoders. Of course, you should first know what encoder is being used, after that, it is easy to use a different encoder. Consider:
'/tmp/foo.txt' asFileReference readStreamEncoded: #utf8 do: [ :in | in upToEnd ].
'/tmp/foo.txt' asFileReference readStreamEncoded: #windows1252 do: [ :in | in upToEnd ].
'/tmp/foo.txt' asFileReference readStreamEncoded: #latin1 do: [ :in | in upToEnd ].
ZnCharacterEncoder knownEncodingIdentifiers.
#windows1252 asZnCharacterEncoder.
If you could post a small example of your file, I could try to help. It will probably be #windows1252 or #latin1.
HTH,
Sven
participants (4)
-
Bernardo Ezequiel Contreras -
craig -
Robert Briggs -
Sven Van Caekenberghe