The catch clause works in conjunction with fan.sys.Err.make - if the exception is already a Fan type, its returned, a new instance is not created. A new instance is created only if the the exception was native and needs to be wrapped in a Fantom type.
vkuzkokovMon 21 Feb 2011
What if it doesn't need to be wrapped? The problem is that Err.make saves only error message losing any other properties of caught Error.
andyMon 21 Feb 2011
It has to be wrapped so its a valid Fantom object. Is there a particular property you're interested in? Can we just fix that code to properly wrap with a Fantom Err type?
brianMon 21 Feb 2011
Side note: originally in Java/C# everything subclassed a single fan.sys.Obj class. Then in Dec 2009 when we switched to value types, we built out infrastructure to support classes like Boolean, Long, etc natively. As part of that, I've always wanted to switch fan.sys.Err to be a subclass of RuntimeException so that we extend rather than wrap native exceptions. This idea is captured in ticket 717. But at this point it is a pretty big breaking change to Java code (and its a huge project), so I am a bit wary of doing it.
vkuzkokovMon 21 Feb 2011
Properties I'm most interested in are rhinoException and javaException. BTW, why can't we in fact wrap the Error and give access to it via something like err->jsErr?
andyMon 21 Feb 2011
The big problem is we don't have JavaScript FFI yet - so you can't use that object directly from Fantom code. Thats what really makes this all a bit tricky.
If you need to workaround that right now - you can always use a native method and have full access however you needed.
vkuzkokovMon 21 Feb 2011
This workaround is not always applicable. Here's scenario:
Some JavaScript Error is thrown
Any catch block inside another pod wraps this Error to sys::Err
Now I get sys::Err and can't retrieve the information I need.
vkuzkokov Sun 20 Feb 2011
Here's short example
I wanted to focus on a catch block generated:
So if we catch some internal error, we throw an instance different from the one we actually got. Here's proposed patch:
andy Mon 21 Feb 2011
The catch clause works in conjunction with
fan.sys.Err.make
- if the exception is already a Fan type, its returned, a new instance is not created. A new instance is created only if the the exception was native and needs to be wrapped in a Fantom type.vkuzkokov Mon 21 Feb 2011
What if it doesn't need to be wrapped? The problem is that
Err.make
saves only error message losing any other properties of caught Error.andy Mon 21 Feb 2011
It has to be wrapped so its a valid Fantom object. Is there a particular property you're interested in? Can we just fix that code to properly wrap with a Fantom Err type?
brian Mon 21 Feb 2011
Side note: originally in Java/C# everything subclassed a single fan.sys.Obj class. Then in Dec 2009 when we switched to value types, we built out infrastructure to support classes like Boolean, Long, etc natively. As part of that, I've always wanted to switch fan.sys.Err to be a subclass of RuntimeException so that we extend rather than wrap native exceptions. This idea is captured in ticket 717. But at this point it is a pretty big breaking change to Java code (and its a huge project), so I am a bit wary of doing it.
vkuzkokov Mon 21 Feb 2011
Properties I'm most interested in are
rhinoException
andjavaException
. BTW, why can't we in fact wrap theError
and give access to it via something likeerr->jsErr
?andy Mon 21 Feb 2011
The big problem is we don't have JavaScript FFI yet - so you can't use that object directly from Fantom code. Thats what really makes this all a bit tricky.
If you need to workaround that right now - you can always use a native method and have full access however you needed.
vkuzkokov Mon 21 Feb 2011
This workaround is not always applicable. Here's scenario:
Error
is thrownError
tosys::Err
sys::Err
and can't retrieve the information I need.