<https://trycf.com/gist/56e3cc737649a446bc5a05f7b2...
# lucee
a
https://trycf.com/gist/56e3cc737649a446bc5a05f7b2aa3e79/lucee5?theme=monokai Note the error message "null can not be casted to a Struct" There's a coupla grammar issues there. "cast" is the past tense of "cast": "casted" isn't a thing. Secondly: if one was in there to fix it, consider also tweaking "cannot" to be "can not". Whilst both are correct; one would tend to use "can not" to emphasise the "not" part when appropriate, and is perhaps not the better of the two options here. "cannot" is by far the more common spelling of this.
a
Added the PR on mobile while drinking a coffee.
a
Yeah that might be jumping the gun a bit. There should probably be a ticket and an undertaking to do the work before diving in and fixing part of it. NB: this is not the only instance of this particular string in the app, and it probs oughta be handled comprehensively. Or... poss... not at all.
This is why I raise things for discussion & then perhaps ultimately raise a ticket, rather than diving in. That and I can't be arsed working out how to config the project, build it, run the tests (any change should have a test right? RIGHT?? ;-)) etc.
I've also just noticed that "Struct" should probably be "struct"(*). I think we've got some German noun-capitalisation going on here. (*) If it was the name of the class that defines a struct I'd say the capitalisation would be legit, but it's not.
z
Changing the text of an exception doesn't necessarily require a test or a ticket IMHO. "Adam was casted as the naughty boy in Home Alone 4" I agree with cannot, we tend to avoid can't due to the apostrophe
✅ 2
a
Disagree re tests. Not so much "test the static string equals the other static string", but for next time when someone goes in and changes it and the test fails, they will at least be encouraged to think through what they're doing, why, and you get the measure-twice, cut-once effect. The problem isn't the added effort putting the test in now; the problem is the test didn't go in in the first place when the code was initially done. But we can't go back and change that. Plus it encourages ppl to get into a good cadence of testing their shit. The ticket(s) here would perhaps be "update all situations where we have said
casted
", and maybe another "update all situations where we say `can not`". Also preempts someone coming back later and going "why did we change this? Oh right 'casted' isn't a word. Duly noted".
It also encourages a cadence of "think about yer work at least enough to create a well-formed ticket describing why yer bothering", rather than being reactive (like here).
z
do you know how many exceptions i have improved in the lucee code base 100s or maybe over 1000??? for just tweaking grammar, i don't think it's needed, where the wrong exception is being thrown, then it makes more sense https://github.com/lucee/Lucee/commit/45504562be07a8f795fa551071f9b812fb80931c anyway, this bug you commented on is more interesting for me to dive and to fix https://luceeserver.atlassian.net/browse/LDEV-2924?focusedCommentId=53556
a
Yeah I wasn't happy about that one.
Easily worked around, that said.
z
image.png
a
Yeah! @zackster usually merges such changes immediately after a quick review in Github. I've PRed some translations (to German) of the Lucee admin or enhanced the docs without adding any tickets, because I think it may set too much side-noise to the jira system and to the dev team. Whenever Zac sees a PR that is relevant to add to JIRA, he adds it "on demand" and link/tag the PR to the jira ticket then afterwads.
a
[shrug]