-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CompiledDataBinder: "Body of catch must have the same type as body of try" exception #224
Comments
Pumelling a couple of AIs eventualy got to the suggestion to change the code to:
which seems to stop the exception throwing, but no idea if it's right.. |
Oof, feels like hitting a moving target here. I'd had an earlier sugestion from Bing AI to change to:
which I thought had worked, but then turned out not to, hence the revised one with the array init'r.. Which made the error go away, but the file didn't parse (all the records returned were full of default values, rather than parsed values) Then I noticed a small problem with the schema in that the column names have leading spaces and the in-code schema definition doesn't. Wasn't aware that it mattered but when I adjusted the schema to have leading spaces, the "Body of.." error returned. I switched CompiledDataBinder to the So perhaps all in this bug report needs to be changed to more like "if one gets the schema wrong, then a bizarre red herring of an exception appears". I think over the time, an good portion of the dev effort I've put in to getting Sylvan working with a new file has centered on error conditions or messages that were difficult to decipher, or where I couldn't get much useful debugging info. If there's a way to improve that it would be great, because I feel like I could eventually reach a stage where I'll swap out for a library that's lower performance purely because it's easier to use and has more comprehensive error messaging |
Sounds like you got it figured out? The original issue is that there was nothing getting bound, because the headers had a space prefixed, which probably should have produced a binding error. Your code uses Would it have been more obvious if an |
Yeah, I've resolved to start off with bindingmode All in future, and then swap it to Any.. Even when I was debugging Sylvan's code today, I'm looking at a vis of the physicalColumns var and pulling my hair out wondering "why are there 54 entities here and every single one of them has no name at all.. infact, no anything at all - all the properties are the default values?" - it was so easy to miss the leading space in the data vs the schema "Any" probably should have a special case for when nothing matches (to my mind Any excludes none, - I think along the same lines as LINQ where |
Actually, thinking on it some more, I think my requirement to use Any is a consequence of not having available the mode that I really, actually want to use.. All notionally means "All columns in file related to All properties in model" but I have columns I don't want to use and for some files I have properties I cannot set (no data for them) but it doesn't matter for those props. I can't use AllColumns or AllProps either for the same reason; sometimes a file will have both unbound cols and result in unassigned props Really, I'd like the schema, if I've used one, to be the driver for an All operation; if I've put columns in the schema that don't exist in the file, or i've mentioned props in the schema that don't exist in the class, then I should get an error so I can correct the code In other words where we now have All/AllX driven by the file/class, have a different mode/setting where it's driven by the schema - do an All, but pretend that columns/props not mentioned in the schema are out of scope |
The data binder can use the |
I've made two changes.
These changes are included in this pre-release package: I'll release a 0.2.13 final release at some point in the near future. |
Not too sure what to do with this one (not a big user of expressions)..
This console app reproduces it with 1.3.5, 0.2.12, and .net 7
The text was updated successfully, but these errors were encountered: