<div dir="ltr"><div>I have been experimenting with throwing an error out of C++ this morning, and it works seamlessly exactly as one would hope. I much prefer an error message that says, "modula.lua line 420: Finale 26.9 required". (To make up a Finale version.)</div><div><br></div><div>Plus, you'll only have to use pcall if you are unwilling to specify MinFinaleVersion in your plugindef.<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 24, 2022 at 10:26 AM Nick Mazuk <<a href="mailto:nick@nickmazuk.com">nick@nickmazuk.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div><div><div>Throwing an error might be redundant. For instance, if the following prints out nil (for instance, if the method doesn't exist on the object):<br></div><div><br></div><div>local entry = finale.FCEntry()<br></div><div>print(entry.FooBar)<br></div><div><br></div><div>then the following will already be thrown an error since nil is not a function:<br></div><div><br></div><div>local entry = finale.FCEntry()<br></div><div>entry:FooBar() — error!<br></div><div><br></div><div>The only advantage I can think of by having RGP Lua throw an error if you even access it is that you'll potentially get more meaningful error messages as a user. As a developer, the plugin will still tell you exactly what line of code threw the error. However, it has the disadvantage that you must use pcall to capture the error and you cannot simply check if the method exists or not (which developers should be doing anyways for any newly added features to RGP Lua).</div></div><div><div style="display:none;border:0px none;width:0px;height:0px;overflow:hidden"><img src="https://r.superhuman.com/wR64BPnkBV3H5ye8eBpwVz6PpWRjj9zWOop00qcWk8xjdNrQGeoIjESPD9eu4hlsDlhLaX4JPcsYm8v_NYYQ2dEyal7k_f8T-ns3kA1g8uHbiKhlseB6ivljoSRUXYKpIKgya0HZDXlfV9FO7-PaanlGUNQrvLCYYSR1CzbZQezG6lca.gif" alt="" style="display: none; border: 0px none; width: 0px; height: 0px; overflow: hidden;" width="1" height="0"></div><br><div></div></div><br><div><div class="gmail_quote">On Wed, Aug 24, 2022 at 5:24 AM, Robert Patterson <span dir="ltr"><<a href="mailto:robert@robertgpatterson.com" target="_blank">robert@robertgpatterson.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote"><div dir="ltr"><div>Throwing an error is a good idea that I hadn't thought of. However, these errors would have to be thrown out of the PDK Framework, which is not Lua. So far, there is no try/catch/throw in the PDK Framework codebase. That is not to say we couldn't start using it, but it will require approvals from the other clients that share that code.</div><div><br></div><div>Meanwhile, if the function is missing you'll get the same behavior. It just won't have as helpful an error message. And by leaving it missing, you don't have to resort to pcall. You can simply test if it is there.</div><div><br></div></div><br><div class="gmail_quote"><div class="gmail_attr" dir="ltr">On Wed, Aug 24, 2022 at 6:18 AM Daniel Grunwald <<a href="mailto:dgr@leng.de" rel="noopener noreferrer" target="_blank">dgr@leng.de</a>> wrote:<br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><p dir="ltr">Hi there, </p>
<p dir="ltr">it seems my first reply didn't get through. So I repeat it. I case you receive this twice you know why. </p>
<p dir="ltr">I am a lua novice having no actual experience in lua so my idea might be foolish. However from what I learned in terms of clean code in other languages I would prefer to raise an error instead of not providing the function.<br>
In order to deal with this users will have to use pcall, as described in <a href="https://www.lua.org/pil/8.4.html" rel="noopener noreferrer" target="_blank">https://www.lua.org/pil/8.4.html</a></p>
<p dir="ltr">Although not knowing if it really is (by lack experience) to me it sounds like a cleaner approach.</p>
<p dir="ltr">However if you like to use the nil-approach I suggest putting "OrNil" as suffix to the function's name so the name indicates it possibly being nil.</p>
<p dir="ltr">Hope this was helpful.</p>
<p dir="ltr">Best regards<br>
Daniel</p>
<p dir="ltr">Von meinem Xperia<img src="https://emojis.superhuman.com/2122.png" alt="™" title="™" style="height: 15px; width: 15px; vertical-align: text-bottom;" width="15" height="15"> von Sony-Smartphone gesendet</p>
<br><br>---- <a href="mailto:jwlua-request@jwmusic.nu" rel="noopener noreferrer" target="_blank">jwlua-request@jwmusic.nu</a> schrieb ----<br><br>Send JWLua mailing list submissions to<br> <a href="mailto:jwlua@jwmusic.nu" rel="noopener noreferrer" target="_blank">jwlua@jwmusic.nu</a><br><br>To subscribe or unsubscribe via the World Wide Web, visit<br> <a href="http://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu" rel="noopener noreferrer" target="_blank">http://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu</a><br>or, via email, send a message with subject or body 'help' to<br> <a href="mailto:jwlua-request@jwmusic.nu" rel="noopener noreferrer" target="_blank">jwlua-request@jwmusic.nu</a><br><br>You can reach the person managing the list at<br> <a href="mailto:jwlua-owner@jwmusic.nu" rel="noopener noreferrer" target="_blank">jwlua-owner@jwmusic.nu</a><br><br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of JWLua digest..."<br><br><br><span>Today</span>'s Topics:<br><br> 1. RFC: Adding Methods/Properties to RGP Lua that only exist in<br> certain Finale versions (Robert Patterson)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: <span>Mon</span>, <span>22 Aug 2022</span> 15:03:<a href="tel:15%20-0500" rel="noopener noreferrer" target="_blank">15 -0500</a><br>From: Robert Patterson <<a href="mailto:robert@robertgpatterson.com" rel="noopener noreferrer" target="_blank">robert@robertgpatterson.com</a>><br>To: "The JW Lua script plug-in." <<a href="mailto:jwlua@jwmusic.nu" rel="noopener noreferrer" target="_blank">jwlua@jwmusic.nu</a>><br>Subject: [JW Lua] RFC: Adding Methods/Properties to RGP Lua that only<br> exist in certain Finale versions<br>Message-ID:<br> <<a href="mailto:CAACnceu23XaymU4XNBZQ-1e6wDdP5xP6-ht8fdk3trUduahrUA@mail.gmail.com" rel="noopener noreferrer" target="_blank">CAACnceu23XaymU4XNBZQ-1e6wDdP5xP6-ht8fdk3trUduahrUA@mail.gmail.com</a>><br>Content-Type: text/plain; charset="utf-8"<br><br>I will soon be adding to RGP Lua some methods and properties that are not<br>available before a certain Finale version. Previously when this has<br>happened, the methods and properties appear in all Finale versions but<br>return a default value in earlier Finale versions where they aren't<br>supported. Until now there has always been an appropriate default value.<br><br>However, these new methods and properties I plan to add do not have useful<br>default values in earlier Finale versions. In fact, it would be a bad idea<br>to return anything at all unless running in an supported Finale version.<br><br>To me the best solution would appear to be not to hook up these methods and<br>properties to Lua if the Finale version doesn't support them. But that<br>means, in perpetuity, Lua programmers will have to check them for `nil`<br>before calling them. Does anyone have other/better ideas?<br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <<a href="http://jwmusic.nu/pipermail/jwlua_jwmusic.nu/attachments/20220822/224e51a5/attachment-0001.html>" rel="noopener noreferrer" target="_blank">http://jwmusic.nu/pipermail/jwlua_jwmusic.nu/attachments/20220822/224e51a5/attachment-0001.html></a>;<br><br>------------------------------<br><br>Subject: Digest Footer<br><br>_______________________________________________<br>JWLua mailing list<br><a href="mailto:JWLua@jwmusic.nu" rel="noopener noreferrer" target="_blank">JWLua@jwmusic.nu</a><br><a href="http://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu" rel="noopener noreferrer" target="_blank">http://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu</a><br><br><br>------------------------------<br><br>End of JWLua Digest, Vol 94, Issue 5<br>************************************<br>_______________________________________________<br>
JWLua mailing list<br>
<a href="mailto:JWLua@jwmusic.nu" rel="noopener noreferrer" target="_blank">JWLua@jwmusic.nu</a><br>
<a rel="noopener noreferrer" href="http://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu" target="_blank">http://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu</a><br>
</blockquote></div>
<p>_______________________________________________
<br>
JWLua mailing list
<br>
<a rel="noopener noreferrer" href="mailto:JWLua@jwmusic.nu" target="_blank">JWLua@jwmusic.nu</a>
<br>
<a href="http://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu" target="_blank">http://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu</a></p></div></div></blockquote></div></div><br></div></div></div>_______________________________________________<br>
JWLua mailing list<br>
<a href="mailto:JWLua@jwmusic.nu" target="_blank">JWLua@jwmusic.nu</a><br>
<a href="http://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu" rel="noreferrer" target="_blank">http://jwmusic.nu/mailman/listinfo/jwlua_jwmusic.nu</a><br>
</blockquote></div>