develooper Front page | perl.datetime | Postings from July 2017

Re: How to check if a DateTime is invalid (again - but this timewithout using eval)?

Thread Previous | Thread Next
From:
Binarus
Date:
July 3, 2017 07:45
Subject:
Re: How to check if a DateTime is invalid (again - but this timewithout using eval)?
Message ID:
a447c509-4bb0-2da1-1b6a-719f3e4bea47@binarus.de
On 02.07.2017 19:01, Thomas Klausner wrote:
> Hi!
> 
> On Sun, Jul 02, 2017 at 11:59:56AM +0200, Binarus wrote:
> 
>> - Most people recommend to "catch the error" DateTime throws when
>> encountering such date-times, but if I got it right, that always
>> involves eval, even when using modules like Try:Tiny and the like, so I
>> don't want to do that.
> 
> As somebody who most likely started on of the threads you mentioned, I 
> have to say that using eval is (as Zefram already said) the right 
> answer.
> 
> I do not know why you do not want to use eval, it's very stable 
> (esp. in recent Perls) and not at all slow and dangerous. 
> 

Thank you very much for your answer. There are multiple reasons why I
didn't want to go that way.

First, I am not a fan of the try-catch stuff (i.e. "error catching") at
all. For example, I have experienced all sorts of glitches and worries
with try-catch in the MS .NET world. stackoverflow.com is full of
questions (and in most cases, fundamentally different answers to the
same question) regarding try-catch-finally in .NET. This is just an
example - IMHO, this whole error catching thing is not a clean concept
from the beginning on (in all programming languages).

Having said this, I know that there are not many people left who have
the same opinion, and of course, I am using what I have to use to reach
my goal, so this is not worth any further discussion.

The second (and by far more important) reason are threads like this one:

https://stackoverflow.com/questions/4006267/what-is-the-best-way-to-handle-exceptions-in-perl

The accepted answer there proposes error handling by eval blocks (as
people here did), but then states: "It's fragile, though, and will break
in a number of subtle edge cases that most people don't think about."
From my experience, I know that I will be the first one to run into one
of these edge cases, whatever they may be.

This answer has 49 upvotes, so can't be too wrong. Now, what should I
make out of that? He doesn't give examples what this subtle edge cases
could be, but I see no reason to mistrust the answer. Given the fact
that I have found similar mysterious statements (i.e. warnings against
eval without further explanation or examples) at other places as well,
how do I know if I am affected?

On the other hand, I have read the eval documentation in perldoc
multiple times now and could not find any hint about when it could fail
or why it could be dangerous (at least, not in the block eval part). I
meanwhile tend to believe perldoc more than any other source; they
usually emphasize what could go wrong in big red letters, and I didn't
find such sections in the block eval documentation part.

Thus, I have decided to use the eval block error catching in that case.

Nevertheless, for the reasons mentioned above, I am not exceptionally
happy about having to do so, and I still would prefer if DateTime would
provide a method to check in advance if a date-time is valid or not.

Again, thanks for your time and expertise.

Regards,

Binarus

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About