I was having some issues running Clipperz test suite with Opera 10.
Looking closer at the failed tests, I have find out that Opera 10 is returning a messed up name and description for Exceptions.
This problem is triggered also running the default MochiKit tests; in MochiKit.Async test actually. The test expects an error with message "foo" (test_MochiKit-Async.html, line 300; trunk version 1525), but the actual value is "foo\r\nstacktrace: n/a; see opera:config#UserPrefs|Exceptions Have Stacktrace".
Opera 10 is appending some extra values to the exception message, screwing up the test; in my case, it alters the behaviour of the whole application, as some execution paths are based on the value of the returned error name.
Any idea on how to fix this problem? or just report it to Opera so that they can fix it for the next release?
This is the type of stuff one would rather not add to work-arounds in
the JavaScript code. Don't understand why Opera can't add stacktraces
as separate properties to their exception objects instead? Or is it
just that they've modified the toString() implementation?
> I was having some issues running Clipperz test suite with Opera 10.
> Looking closer at the failed tests, I have find out that Opera 10 is
> returning a messed up name and description for Exceptions.
> This problem is triggered also running the default MochiKit tests; in
> MochiKit.Async test actually.
> The test expects an error with message "foo"
> (test_MochiKit-Async.html, line 300; trunk version 1525), but the
> actual value is "foo\r\nstacktrace: n/a; see
> opera:config#UserPrefs|Exceptions Have Stacktrace".
> Opera 10 is appending some extra values to the exception message,
> screwing up the test; in my case, it alters the behaviour of the whole
> application, as some execution paths are based on the value of the
> returned error name.
> Any idea on how to fix this problem? or just report it to Opera so
> that they can fix it for the next release?
I agree with you about trying to avoid work-arounds; but I haven't
found any way to report a 'simple' Javascript issue to Opera itself.
I have investigated if the problem is caused by a different toString()
implementation, but I don't think so, as the extra stack info is
appended to the 'name' and 'message' extension property also.
On Sat, Jul 11, 2009 at 8:57 PM, Per Cederberg<cederb...@gmail.com> wrote:
> This is the type of stuff one would rather not add to work-arounds in
> the JavaScript code. Don't understand why Opera can't add stacktraces
> as separate properties to their exception objects instead? Or is it
> just that they've modified the toString() implementation?
> Cheers,
> /Per
> On Sat, Jul 11, 2009 at 18:57, Giulio Cesare
> Solaroli<giulio.ces...@gmail.com> wrote:
>> Hello,
>> I was having some issues running Clipperz test suite with Opera 10.
>> Looking closer at the failed tests, I have find out that Opera 10 is
>> returning a messed up name and description for Exceptions.
>> This problem is triggered also running the default MochiKit tests; in
>> MochiKit.Async test actually.
>> The test expects an error with message "foo"
>> (test_MochiKit-Async.html, line 300; trunk version 1525), but the
>> actual value is "foo\r\nstacktrace: n/a; see
>> opera:config#UserPrefs|Exceptions Have Stacktrace".
>> Opera 10 is appending some extra values to the exception message,
>> screwing up the test; in my case, it alters the behaviour of the whole
>> application, as some execution paths are based on the value of the
>> returned error name.
>> Any idea on how to fix this problem? or just report it to Opera so
>> that they can fix it for the next release?
|
