Parse errors should throw more informative lexical_cast exceptions

Support
1

Errors when parsing some experiment XML generate an error like this:

00:06:45: ERROR: bad lexical cast: source type value could not be interpreted as target
00:06:45: ERROR: Experiment packaging failed: bad lexical cast: source type value could not be interpreted as target

This doesn’t get you very far in figuring out what is wrong. To track this down I needed to run the Client in a debugger and trap on the C++ exception bad_lexical_cast (thrown by boost). Then, you can get a nice stack trace. (see attached; seems that the problem is MWorks doesn’t support expressions in the parameter to the range replicator)

two suggestions:
It would be nice to have the exception show its arguments when thrown. If I understand correctly, many parse errors catch these exceptions and throw more informative ones. But when bad_lexical_cast leaks through it would be nice to see XML line number, C++ backtrace (to see which code is handling the XML tag), and parameters (from_string, to_string, etc).

Also, it would be useful to support expressions in from_ and to_ of range replicators (and in block and trial “nsamples” as well). I’d like to use “nframes” as a parameter in the XML and then have several range replicators use that value rather than having to change the XML in several places whenever the parameter changes. However, this is a low priority.

Thanks,
Mark

2

Attachment: Screen_shot_2010-07-19_at_1.14.46_PM.png (114 KB)

3

Hi Mark,

It would be nice to have the exception show its arguments when thrown. If I understand correctly, many parse errors catch these exceptions and throw more informative ones. But when bad_lexical_cast leaks through it would be nice to see XML line number, C++ backtrace (to see which code is handling the XML tag), and parameters (from_string, to_string, etc).

Agreed. I’ve open a ticket for this.

Also, it would be useful to support expressions in from and to of range replicators (and in block and trial “nsamples” as well).

Also agreed, although this is more complicated, as range replicators are expanded at parse time, rather than run time. I’ve opened a ticket for this, too.

Thanks,
Chris

4

Hi Chris,

Also agreed, although this is more complicated, as range replicators are expanded at parse time, rather than run time. I’ve opened a ticket for this, too.

A first useful step would allow them to take their values at parse time from variables (so that you could use a variable as a constant and only edit one place in the XML).

Thanks for all this!
Mark

5

Hi Mark,

As of tonight’s nightly build, the range replicator parameters “from”, “to”, and “step” can be arbitrary expressions. In particular, you can store their values in variables, and then reference the variables in multiple replicators.

The nsamples parameter of protocol/block/trial/list does not support expressions yet, but this will come for free once we upgrade those components to use the “new-style” parameter-parsing mechanisms.

Cheers,
Chris

6

THIS is awesome. Thank you, it greatly simplifies our code. This is a surprise - I didn’t expect this change for a while.

It will probably take me 6-8 weeks to test this; let me know if I can do anything more limited sooner.
Best
Mark