Robert Stone wrote:

Greetings,

Sounds like you are looking for "warnings" and "show_errors" as documented in http://search.cpan.org/~xsawyerx/Dancer-1.3110/lib/Dancer/Config.pm

Thanks, Robert, for reminding me where to look. I agree that in general, it makes sense to give code more scrutiny during development. Joel Roth

I typically put these configuration values in my environment configs so that in development mode I can get all the juicy errors and warnings while in production they are suppressed and replaced with your standard error pages. I'd welcome any additional feedback or best practices with respect to this.

Hope you find the above useful.

Best Regards, Robert Stone

On 5/2/2014 5:53 PM, Joel Roth wrote:

...

Is it a configuration thing?

Perl usually lets *me* decide how warnings should be handled. Does Dancer allow it too?

If it is a design decision, is there a theory behind this that is written up somewhere?

kind regards,

Joel

_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users

-- Joel Roth

Warren Young wrote:

On 5/2/2014 22:51, Joel Roth wrote:

...

I agree that in general, it makes sense to give code more scrutiny during development.

I've found that most of the time, the "fatal warnings" you get when you follow this practice are just silly things. Mostly, it's complaints about uninitialized variables used in strings:

my $foo; ...then later... debug "Lorem ipsum $foo dolor sic amet"

Dancer stops the whole world, as though this has a real consequence, when it really does not. You can start feeling that Dancer has some Chicken Little DNA in it.

The latest thing I notice is that a form submitted by a POST request with empty fields triggers this. And the following construction doesn't prevent it. my $foo; { no warnings 'uninitialized'; say "empty $foo" }

However, occasionally it does catch a real problem, something you wouldn't want to appear in production.

So I tolerate it, and encourage you to, as well. :)

Well, up to know I didn't much investigate the Mojolicious way, tho Galileo seems to be a pretty smart and good-looking little app. -- Joel Roth

Greetings, I think the feedback shared has been fantastic. In the same vein, this seemed like a good time to point out a little gotcha I've run into before. my $foo = params 'foo' || ''; This will work a lot of the time, but the problem is that if the value of params 'foo' is "falsey" then it will be replaced with ''. This may or may not be what you want. In cases when I want to specify a default value for a form field that is completely undefined I use: my $foo = params 'foo' // ''; This is especially useful when creating web services where it is actually possible for a developer to leave a field completely undefined. Moreover, this could also be relevant for standard web usage especially if you are getting ajaxy. Hope that saves you some time with the debugger :) Best Regards, Robert Stone ----- Original Message ----- From: "Warren Young" <warren@etr-usa.com> To: "Perl Dancer users mailing list" <dancer-users@dancer.pm> Sent: Monday, May 5, 2014 3:55:19 PM Subject: Re: [dancer-users] Why do warnings cause Dancer to fail? On 5/5/2014 11:39, Joel Roth wrote:

And the following construction doesn't prevent it.

my $foo;

It wouldn't. You'd need to say something more like my $foo = params 'foo' || ''; _______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users

On 05/06/2014 11:40 AM, Warren Young wrote:

On 5/5/2014 16:51, Robert Stone wrote:

...

my $foo = params 'foo' // '';

Alas for those of us who still must support Perl 5.8. That operator was introduced in 5.10.

A pre-5.10 equivalent to defined-or that avoids the pitfall with falsey values: my $foo = ( defined params 'foo' ) ? params 'foo' : '';

On Mon, May 05, 2014 at 09:13:57AM -0600, Warren Young wrote:

I've found that most of the time, the "fatal warnings" you get when you follow this practice are just silly things. Mostly, it's complaints about uninitialized variables used in strings:

my $foo; ...then later... debug "Lorem ipsum $foo dolor sic amet"

Dancer stops the whole world, as though this has a real consequence,

Debugging information like that is most useful when it is accurate, so rather than just blindly interpolating, I'd write that code something like this, so that when I'm looking at it later I can distinguish between undef and the empty string ... debug join(' ', "Lorem ipsum", (defined($foo) ? "'$foo'" : '[undef]'), "dolor sic amet" ); Or if I were feeling really paranoid: { use Data::Dumper; local $Data::Dumper::Indent = 1; debug "Lorem ipsum dolor sic amet".Dumper($foo); } -- David Cantrell | even more awesome than a panda-fur coat fdisk format reinstall, doo-dah, doo-dah; fdisk format reinstall, it's the Windows way