John Wilson wrote: > On Dec 22, 2007 3:48 AM, John Cowan <[EMAIL PROTECTED]> wrote: >> In the language I"m implementing, catching is done not based on the >> class of the thrown object but on its identity. That is, in the >> general case, the throw will have to wrap the object in a descendant >> of RuntimeException (which I call CatchPoint), and then each catcher >> routine will begin with a line like "if (e.object != object_we_want) >> throw e;" in order to rethrow the exception if the object is not >> identical.
This is what we do in JRuby; all Ruby exceptions (RubyException type in Java) get wrapped in a RuntimeException descendant (RaiseException), and in-language rescue/catch clauses then catch all RaiseExceptions and perform the appropriate operation (which in Ruby is equivalent to a case/when statement). For general exception handling, this is basically the only way, since at compile time it's impossible to know in Ruby what types are actually being caught. Your case is different there. >> Often, but not always, the object is a constant and its identity is >> known at compile time. Is it worthwhile creating unique subclasses of >> CatchPoint, one for each such manifest thrown object, so that the >> above test can be omitted? If omitting the test does not change the semantics of your language, that I'd suspect it would be very useful. And... > I think you should see quite a performance improvement if you do this. > So, as long as you aren't generating very large numbers of these > specialised classes, I think I'd do it. it would probably also improve performance. But if you're not implementing something like non-local flow control, which is very sensitive to exception handling cost, perhaps it doesn't make a difference? > On a related topic, John Rose has written about efficient use of > Exceptions > (http://blogs.sun.com/jrose/entry/longjumps_considered_inexpensive). > This may not be relevant to what you are doing here but it's useful > stuff to know. I don't think it's directly relevant, unless John C is using exceptions for flow control. What I would be interested in hearing is if N catches are more expensive than one catch, or if catching at all already has done the damage and adding additional catches doesn't make much difference. For exceptions bubbling out from deep inside an API, in JRuby it will essentially be caught at several places. Though we have no real way to avoid that, it would be useful to know the real cost. Twould be a useful benchmark to run... - Charlie --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
