#30 Restriction using throw statement.

General (151)
Allan Crooks


This code in BeanShell works.
throw new Exception();

This code should, but doesn't, because the BeanShell
throw statement has to be used in tandem with an
Exception, rather than a Throwable object.
throw new Throwable();


  • Pat Niemeyer
    Pat Niemeyer

    Logged In: YES

    The original reason for this is that in order to handle the
    throwable internally we would have to catch throwables in
    the try/catch block implementation. This is a dangerous
    thing to do in general... Anything that goes wrong
    internally in the interpreter would be gummed up in the
    scripted try/catch mechanism. I will continue to think
    about this...

  • Pat Niemeyer
    Pat Niemeyer

    • priority: 5 --> 2
  • Allan Crooks
    Allan Crooks

    Logged In: YES

    If all errors which the interpreter all share a common
    baseclass (InterpreterError or something like that), then
    you could do this:

    try {blah();}
    catch (Throwable t) {
    if (t instanceof InterpreterError) {throw t;}
    else {do_whatever();}

    That way InterpreterErrors get through the try-catch blocks.

    Most people should extend from Exception. Errors are for
    the VM to throw, and Throwable is just a common base class
    for the two. But Sun didn't package-protect Throwable's
    constructor, meaning that some people create their own
    exceptions which do not inherit from Exceptions, but from
    And of course, once they made that mistake, there's no
    way of changing it. :)

    But that's just me going off the point. Is that a viable

  • Pat Niemeyer
    Pat Niemeyer

    Logged In: YES

    Wait, I was confused before... We don't have to catch
    throwable. Either an explicit throw or one produced by the
    reflection API via method invocation will be wrapped in a
    TargetError before it gets to that point. So we just need
    to make sure those areas can handle it.

    My confusion was not so much related to how we would handle
    errors we wanted to pass through, as in avoiding catching
    legitimate (bug related) exceptions thrown by the
    interpreter (other than InterpreterError). Right now the
    practice is to wrap any legitimate error (including
    InterpreterError after thrown from the sub-interpreter) with
    a TargetExcption. I was (wrongly) thinking that widening to
    Throwable would involve a catch(Throwable) somewhere, but
    that's not the case.

    Thanks for the followup. I'll re-examine this bug soon.