Open DavyLandman opened 1 week ago
I'm for introducing a generic mechanism that can translate java exceptions to rascal exceptions without all these catch blocks.
Since all these calls go through the javabridge we could specialize IOException and even derive constructors for exception classes we haven't thought about yet. And deal with the corner cases like null messages at the same time. Instead of catch, all these methods would declare that they "throw" the checked exception.
For the compiler some more information is needed to be able to handle checked exceptions. * A simple bytecode analysis based could provide the checked exception classes to the Compiler so that they can be caught and handled like above.
A large part of this is described in the "Events" RAP.
To add onto this, I think it's not just Exceptions, also other exceptions allow for a null message. So adding something in JavaBridge and allowing checked exceptions should be a good idea!
@PaulKlint could something like this work for the compiler if we add some information to the signatures of java
functions? Like @javaThrows{java.lang.IOException}
or something?
Sometimes you get a print like:
Which is caused by this pattern in Prelude.java:
It's not just readBinaryValueFile, but all those exception translators. The
getMessage
can return null, so we should in that case think of something better to print, like the class name? or use thetoString()
of the exception?