Hmm, I'd be a little careful with this, as it can obscure the source of
failures when code elsewhere (naively?) assumes that its catch (Exception)
clause will catch everything.  (Ola, you may recall that I tracked down a
byte-code generation bug in JavaProxyClassFactory that had remained
unresolved for a while for just this reason.)  I'd be sure to document it
clearly, and I think in that case JumpException should be renamed JumpError,
for correctness, but more to underscore the point for the unwary.

I think in general we should discourage this (ab)use of Error in JRuby code
-- Error ought really be reserved for unexpected conditions that impact the
viability/integrity of the system.  I recognize that in this case it's being
used to counter the abuse of catch (Exception); unfortunately, that abuse is
pervasive (I've been guilty of it myself at times); long-term we should try
to purge it from the code base.

But for now, I guess we can make an, um, exception. ;)

-Bill


On 7/26/07, Nick Sieger <[EMAIL PROTECTED]> wrote:

On 7/25/07, Nick Sieger <[EMAIL PROTECTED] > wrote:

> On 7/24/07, Ola Bini <[EMAIL PROTECTED]> wrote:
> >
> > Just noticed a thing, thanks to John Lam. Our JumpExceptions derive
> > from
> > RuntimeException. That means that code that will catch(Exception) will
> > stop flow control, if it happens at the wrong place. To get around
> > this,
> > I believe we should consider going to have JumpExceptions based on
> > java.lang.Error instead.
>
>
> Seems reasonable.  For that matter, why not just extend Throwable?
> They're not Errors either, really.
>

Nevermind (Wow, after all these years I didn't notice Throwable was
checked!)  Of course we want unchecked exceptions, so extending Error should
be fine.

/Nick




Reply via email to