IO exceptions sometimes have a null message, we should detect that and throw something else.

[DavyLandman]

Sometimes you get a print like:

readBinaryValueFile: ... throws null
exception... throws: IO("")
stacktrace

Which is caused by this pattern in Prelude.java:

		catch (IOException e) {
			System.err.println("readBinaryValueFile: " + loc + " throws " + e.getMessage());
			throw RuntimeExceptionFactory.io(values.string(e.getMessage()));
		}

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 the toString() of the exception?

[jurgenvinju]

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.

• The "throws" information on the function signature could be used, if it properly reflects the java exception somehow. I.e. a bidirectional mapping between java exception classes and rascal exception constructors is required for this.

[jurgenvinju]

A large part of this is described in the "Events" RAP.

[DavyLandman]

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!

[jurgenvinju]

@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?