Forum: JRuby 1.7.0-preview1 behaviour change checks

42b570f6f4312a872c2fc671e3ddc82b?d=identicon&s=25 Trejkaz Xx (trejkaz)
on 2012-07-04 02:31
(Received via mailing list)
Hi all.

I did a test upgrade to 1.7.0 and some of my tests for JRuby's
behaviour are failing so I just want to check to see what's going on.

1. These fail because e.getCause() is an EvalFailedException, whereas
it was previously RaiseException. In both cases running the script in
MRI causes an exception to be "raised"... so I guess now I want to
also know what causes "Raise"Exception.

    @Test
    public void testErrorBehaviourForErrorFromJavaSide() throws
Exception
    {
        ScriptEngineManager manager = new ScriptEngineManager();
        ScriptEngine engine = manager.getEngineByExtension("rb");

        try
        {
            Runnable runnable = new Runnable()
            {
                @Override
                public void run()
                {
                    throw new RuntimeException("Got an error");
                }
            };

            engine.put("runnable", runnable);
            engine.put("$runnable", runnable);

            engine.eval("$runnable.run()");
            fail("Expected ScriptException");
        }
        catch (ScriptException e)
        {
            RaiseException cause = (RaiseException) e.getCause();

            // Now we expect the real exception in here.
            RuntimeException realCause = (RuntimeException)
cause.getCause();

            assertEquals("Wrong runtime exception", "Got an error",
realCause.getMessage());
        }
    }

    @Test
    public void testErrorBehaviourForUnknownSymbol() throws Exception
    {
        ScriptEngineManager manager = new ScriptEngineManager();
        ScriptEngine engine = manager.getEngineByExtension("rb");

        try
        {
            engine.eval("# extra lines to confirm that \n" +
                        "# the line number is accurate \n" +
                        "no_method_with_this_name");
            fail("Expected ScriptException");
        }
        catch (ScriptException e)
        {
            EvalFailedException cause = (EvalFailedException)
e.getCause();
            // Neither printStackTrace nor toString should throw
exceptions.
            cause.toString();
            String stackTrace = ExceptionUtils.getFullStackTrace(cause);
            // Checking that the string starts like this, which is the
hack I applied.
            // MRI starts with this:
            // -:1: undefined local variable or method
            assertTrue("Not seeing the expected error message",
                       stackTrace.contains("(NameError) undefined
local variable or method `no_method_with_this_name' for
main:Object"));
            assertTrue("Not seeing the expected line reference",
                       stackTrace.contains("(<script>:3)"));
        }
    }

2. These both fail with ParseFailedException ("invalid multibyte char
(US-ASCII)") even though I'm passing the script as a string (plus I'm
not using US-ASCII in the first place, so I don't know where JRuby is
pulling that from...) This looks like it might be a particularly nasty
bug.

    @Test
    public void testUnicodeStringOutputDirectlyViaScriptEngine()
throws Exception
    {
        String orig = "\u30C6\u30B9\u30C8";

        ScriptEngineManager manager = new ScriptEngineManager();
        ScriptEngine engine = manager.getEngineByExtension("rb");

        ScriptContext context = new SimpleScriptContext();
        StringWriter writer = new StringWriter();
        context.setWriter(writer);

        Object returnedResult = engine.eval("str = \"" + orig + "\" ;
puts str ; str", context);

        //noinspection ErrorNotRethrown
        try
        {
            assertEquals("Wrong result returned", orig, returnedResult);
            assertEquals("Wrong result printed", orig,
writer.toString().trim());

            fail("Expected AssertionError.  This is a good thing -
update the test.");
        }
        catch (AssertionError e)
        {
            // Currently expected due to the bug.
        }
    }

    @Test
    public void testUnicodeStringOutputDirectlyViaScriptContainer()
throws Exception
    {
        String orig = "\u30C6\u30B9\u30C8";

        ScriptingContainer container = new ScriptingContainer();
        StringWriter writer = new StringWriter();
        container.setWriter(writer);

        Object returnedResult = container.runScriptlet("str = \"" +
orig + "\" ; puts str ; str");

        //noinspection ErrorNotRethrown
        try
        {
            assertEquals("Wrong result returned", orig, returnedResult);
            assertEquals("Wrong result printed", orig,
writer.toString().trim());

            fail("Expected AssertionError.  This is a good thing -
update the test.");
        }
        catch (AssertionError e)
        {
            // Currently expected due to the bug.
        }
    }



TX
42b570f6f4312a872c2fc671e3ddc82b?d=identicon&s=25 Trejkaz Xx (trejkaz)
on 2012-07-04 04:00
(Received via mailing list)
On Wed, Jul 4, 2012 at 10:30 AM, Trejkaz <trejkaz@trypticon.org> wrote:
> 2. These both fail with ParseFailedException ("invalid multibyte char
> (US-ASCII)") even though I'm passing the script as a string (plus I'm
> not using US-ASCII in the first place, so I don't know where JRuby is
> pulling that from...) This looks like it might be a particularly nasty
> bug.

As an additional bit of info for this, if I set the compat version
back to 1.8, the problem goes away and the tests hit the fail() line
so I can remove the catches and they still pass. So behaviour in the
newest JRuby is better for non-ASCII scripts as long as you run under
1.8, but 1.9 is a bit shaky.

If you do put the "#encoding: utf-8" header at the top of your script
the problem goes away too. I'm surprised it would be needed when the
source string is from Java code though - wouldn't the encoding of a
String script be UTF-16 if anything? US-ASCII is a bit surprising.

TX
This topic is locked and can not be replied to.