On 03.07.2017 17:11, Thomas Klausner wrote:

> block eval indeed had some not-totally-implausible corner cases, as 
> listed here:
> https://metacpan.org/pod/Try::Tiny#BACKGROUND
> 
> AFAIK at least some of them were fixed in Perl 5.14:
> http://blog.twoshortplanks.com/2011/06/06/unexceptional-exceptions-in-perl-5-14/
 Thank you very much for the links. That was interesting reading. I
didn't read Perl's own documentation about $@, but will do in the next days.

I don't care about the problems with $@ because I don't use it.
Actually, all subs I have used until now (from core or from modules),
either return reasonable values or provide other ways besides exception
handling to detect errors, and I've always been using that to handle
errors. None of the subs I have used so far are dying in case of errors
(provided that the respective error could be handled reasonably at all)
(unless I have missed something; at least, I never have experienced such
behavior even in the earliest stages of development where many errors
occur during testing).

So, in the moment when I decided to follow everybody's advice and to use
eval to solve my problem, it was clear to me that I just would check if
the eval would return undef to detect if DateTime -> new() had died
inside the eval. In that specific case, I don't need to know more.

> And regarding using exceptions or not: I don't think you have a choice 
> here. You will always encounter exceptions (disk full, DB-Server 
> crashed, ...), so you might as well get used to them and incorporate 
> them in your toolkit. I know nothing about .NET, so maybe exceptions are 
> horrible there. But in Perl they work quite well, IMO...

You are right. At least, as long as DateTime -> new() just dies in case
of invalid parameters, I obviously have no choice. I admit that it is
easier than I thought, though.

But interestingly enough, this is the very first case where I am
actually forced to use exception handling in Perl; see my remarks above.
This may also be due to the fact that Perl never has been my main
programming language, so I am quite sure that I am doing many things
which an experienced Perl programmer will do another way or won't do at
all, and that I am not using Perl's capabilities at the fullest.

Thank you very much for your help again!

Regards,

Binarus

Reply via email to