[ruby-core:117840] [Ruby master Feature#20484] A new pragma for eager resolution of classes referenced in rescue clauses.
From:
"jfrisby (Jon Frisby) via ruby-core" <ruby-core@...>
Date:
2024-05-12 04:25:28 UTC
List:
ruby-core #117840
Issue #20484 has been updated by jfrisby (Jon Frisby). duerst (Martin D=FCrst) wrote in #note-1: > Can you give an example with actual code to show where you get problems? The problem I ran into is that the exception class was properly named `Some= Module::SomeClass`, but my rescue block had `rescue SomeClass =3D> e`. Of = course, this didn't turn up until an actual exception occurred so it slippe= d by into production. Ultimately, I could of course have prevented it if I had a test that forced= an exception but that's often quite a lot of work. Having a pragma that r= esolves class names earlier would have surfaced the error much more quickly= with much less effort. ---------------------------------------- Feature #20484: A new pragma for eager resolution of classes referenced in = rescue clauses. https://bugs.ruby-lang.org/issues/20484#change-108243 * Author: jfrisby (Jon Frisby) * Status: Feedback ---------------------------------------- I've been using Ruby for 20 years, and just today learned (the hard way) th= at the class name(s) referenced in a `rescue` clause are not resolved until= an exception occurs. Upon reflection, this behavior probably makes sense in a lot of situations.= Late resolution may simplify code loading for the developer. I would, however, love to see an opt-in feature (a la `frozen-string-litera= l`) to force resolution when the code is loaded/parsed. --=20 https://bugs.ruby-lang.org/ ______________________________________________ ruby-core mailing list -- ruby-core@ml.ruby-lang.org To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-c= ore.ml.ruby-lang.org/