[pm-h] January Houston.pm Meeting

Zakariyya Mughal zaki.mughal at gmail.com
Mon Dec 29 13:28:07 PST 2014


On 2014-12-29 at 14:53:11 -0600, B. Estrade via Houston wrote:
> On Sat, Dec 27, 2014 at 2:37 PM, Robert Stone via Houston <houston at pm.org>
> wrote:
> 
> > Greetings,
> >
> > "Best Practices Gone Bad" sounds awesome.  I'm certainly guilty of taking
> > things to an extreme and this could be a very interesting topic.
> >
> > If you (or anyone else) is looking for a subject I'd love to see something
> > on Try::Catch/Try::Tiny/etc and using a module like Class::MOP to generate
> > your own exception classes dynamically.  I've been "throw-ing" myself for a
> > solid introduction to non-eval based exception handling.
> >
> 
> Not to spoil this topic, because it is a great one.
> 
> Exception::Class comes to mind for dynamic exception creation.  It offers
> some nice convenience methods. The compelling feature for me is that it
> lets you minimize the number of exceptions required ahead of time by
> providing easy inheritance.

I was actually looking around for alternatives to `Exception::Class` &
`Throwable` last week and I found `failures`
<https://metacpan.org/pod/failures> to be a nice, minimal solution. I
used it in `Statistics::NiceR` [^1] and it was as simple as

    # Error.pm
    package Statistics::NiceR::Error;

    use custom::failures qw/Conversion::RtoPerl Conversion::PerltoR RInterpreter/;

    1;
    __END__

and elsewhere:

    # Rinline.pm
    use Statistics::NiceR::Error;
    # snip...
    Statistics::NiceR::Error::RInterpreter->throw("R executable not found");
    # snip...

And the exceptions are hierarchical: both the exception classes
`Statistics::NiceR::Error::Conversion::RtoPerl` and
`Statistics::NiceR::Error::Conversion::PerltoR` are also subclasses of
`Statistics::NiceR::Error:Conversion`.

Cheers,
- Zaki Mughal

[^1]: <https://github.com/zmughal/p5-Statistics-NiceR/blob/master/lib/Statistics/NiceR/Error.pm>


> 
> It's also my experience that while Try::Tiny offers some nice conveniences
> over eval{}, there are some where eval{} is still nice to have around.
> 
> 
> >
> > Looking forward to the next meeting.
> >
> >
> Me, too.
> 
> Brett
> 
> 
> > Best Regards,
> > Robert Stone
> >
> > ----- Original Message -----
> > From: "G. Wade Johnson via Houston" <houston at pm.org>
> > To: "Houston Perl Mongers" <houston at pm.org>
> > Sent: Saturday, December 27, 2014 9:52:54 AM
> > Subject: [pm-h] January Houston.pm Meeting
> >
> > I have a couple ideas I'm thinking about presenting for January's
> > Houston.pm meeting. Does anyone have an opinion on which they would
> > rather hear about:
> >
> >   * Validation using the Value object pattern
> >   * Best Practices Gone Bad
> >
> > If no one has a better suggestion, I will present one of these at the
> > January meeting.
> >
> > G. Wade
> > --
> > Those who live by the sword get shot by those who don't.
> > _______________________________________________
> > Houston mailing list
> > Houston at pm.org
> > http://mail.pm.org/mailman/listinfo/houston
> > Website: http://houston.pm.org/
> > _______________________________________________
> > Houston mailing list
> > Houston at pm.org
> > http://mail.pm.org/mailman/listinfo/houston
> > Website: http://houston.pm.org/
> >

> _______________________________________________
> Houston mailing list
> Houston at pm.org
> http://mail.pm.org/mailman/listinfo/houston
> Website: http://houston.pm.org/



More information about the Houston mailing list