[Dancer-users] User-friendly errors on YAML parsing failures (was: Re: dancer croaking with a strange error in config.yml)

[Daniel Perrett]

Is indenting with tabs a problem specific to Dancer users? I would say 
not, unless we count "not knowing YAML" as a likely property of Dancer 
users

Therefore, I would think if it is worth implementing this, it is worth 
doing so in the YAML module. 

If "not knowing YAML" is a likely property of Dancer users, then updating 
the documentation would seem a simpler solution than writing a custom 
error checker feature. 

Interestingly, the documentation already states that config.yml is a YAML 
file. 

Config.pm currently reads:

A better way of defining settings exists: using YAML file. For this to be
possible, you have to install the L<YAML> module. If a file named 
B<config.yml>
exists in the application directory, it will be loaded, as a setting 
group.

It could read (note "a YAML file" on first line):

A better way of defining settings exists: using a YAML file. For this to 
be
possible, you have to install the L<YAML> module. If a file named 
B<config.yml>
exists in the application directory, it will be loaded, as a setting 
group.
If the file exists but is not valid YAML (for example, if it contains 
unquoted 
tab characters or does not end in a new line), YAML - and Dancer - will 
die.

As an aside, I don't understand the phrase "as a setting group". Is it a 
group of settings or a group which is setting something else? Does the 
group have an identity of some kind, distinct from other setting groups 
(if so, how is it accessed?), or is it simply an anonymous list of 
key/value pairs which will be mixed in with other settings?

Are there restrictions on the YAML files which are accepted - e.g. do they 
need to evaluate to a hash-like structure or an array-like structure? (I'm 
guessing hash)

What is the priority of settings loaded through config.yml - are they 
overwritten by 'set' commands executed after "use Dancer;"? (I'm guessing 
'yes')

Daniel



From:   David Precious <davidp at preshweb.co.uk>
To:     brian at massassi.com
Cc:     dancer-users at perldancer.org
Date:   14/11/2011 16:27
Subject:        Re: [Dancer-users] User-friendly errors on YAML parsing 
failures        (was: Re: dancer croaking with a strange error in 
config.yml)
Sent by:        dancer-users-bounces at perldancer.org



On Monday 14 November 2011 16:16:29 Brian E. Lozier wrote:
> On Mon, Nov 14, 2011 at 8:11 AM, David Precious <davidp at preshweb.co.uk> 
> > Also, if the parsing failed, open config.yml and skim over it, and 
report
> > any lines which included tabs, with the line number.
> > 
> > This would be a fairly small amount of code, and would only come into
> > play if the parsing of config.yml failed (in which case, the app is
> > unlikely to start anyway, so it's not like it's extra complexity /
> > expense in the majority of cases).
> 
> It seems like it would be better to contribute to the YAML module
> itself so it could report errors like this, as opposed to doing
> post-processing on an already-failed file. 

Hmm, yeah, that could make sense - although I think YAML.pm is to be 
replaced 
with essentially YAML::Any at some point.  Getting all the parsers to 
output a 
friendly message is likely harder than just outputting a fairly generic 
message ourselves.

We could have the message refer to an FAQ entry which lists various common 

mistakes in YAML for more details, perhaps.

> Also, aren't tabs allowed
> inside quoted values?  By the time you take into account all the valid
> possibilities, you will have rewritten a YAML parser.

Yeah, that's why I mentioned earlier in the message "look for any tabs in 
the 
file (before any non-whitespace chars)" - yes, tabs within quoted values 
should be valid, so I'd look only for e.g. /^\s*\t/ or similar.
 
Cheers

Dave P

_______________________________________________
Dancer-users mailing list
Dancer-users at perldancer.org
http://www.backup-manager.org/cgi-bin/listinfo/dancer-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.backup-manager.org/pipermail/dancer-users/attachments/20111114/f32e657c/attachment-0001.htm>