Compatible Java exceptions?

Ucodia

Hi everyone,

I just started with Processing and I was wondering if there was some kind of cross platform exception between Java and JavaScript modes?

I am developing most of my sketches in Java mode but as long as I switch to JavaScript mode, the Java exceptions my code is throwing are not supported and error messages are swallowed along.

Uncaught Processing.js: Unable to execute pjs sketch: ReferenceError: RuntimeException is not defined

Any idea how I can solve that or if there is a list of compatible exceptions?

Thanks.

quark

There is no compatability between Java and Javascript they are very different languages. Devoloping an application in Java mode and then switching to Javascript seems like a good idea but for an application of any size it will rarely work first time and it is really hard to find and replace the Java bits that can't be converted.

Ucodia

Thanks for your answer. I am now developing with JavaScript in mind and I actually wish to write code that runs on both platforms as much as possible. My goal is not switch, it is to stay compatible.

So I could maybe reformulate my question to "Is there a way to manage exception for cross platform Processing code?"

PhiLho

Basically, to have code "that runs on both platforms", avoid any feature not in the Reference page.

Things like ArrayList are listed, and so were made compatible.

Exceptions are rarely used in Processing, and it even carefully catch them to avoid them showing in sketches, so they are not referenced, and therefore are not cross-platform.

GoToLoop

JavaScript Mode was made as a bridge between Java Mode & Processing.js project.
Basically, it mostly converts Processing API from Java to JS! It wasn't meant to know the whole Java! :-S

For a successfully transpile conversion, Java & JS' APIs gotta match!
For example: most of class Math's methods exists for both Java & JS:

• http://docs.oracle.com/javase/8/docs/api/java/lang/Math.html
• https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math

Another coincidence is class Date:

• http://docs.oracle.com/javase/8/docs/api/java/util/Date.html
• https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date

An online cross-mode example: http://studio.processingtogether.com/sp/pad/export/ro.9to4yV59zus7B/latest

However, those API coincidence matches are rare! :o3
As you've already witnessed just now, there's no RuntimeException class in JS! [-X
But what a surprise luck, instead there's an Error class match. And its effects are very similar:

• http://docs.oracle.com/javase/8/docs/api/java/lang/Error.html
• https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error

Check it out my own cross-mode example below: :)>-

// forum.processing.org/two/discussion/7317/compatible-java-exceptions

Dummy d;

void setup() {
  try {
    d = new Dummy(-10);
    //d = new Dummy(100);
  }

  catch (Error cause) {
    println("Oh noes!\t" + cause);
  }

  println(d);
  exit();
}

public class Dummy {
  int n;

  Dummy(int nn) {
    if (nn <= 0)  throw new Error("Positive non-zero values only!");
    n = nn;
  }

  String toString() {
    return n + "";
  }
}

PhiLho

"Another coincidence is class Date:"
I don't think that's a coincidence. The JavaScript name has been forged because Java was already popular when JavaScript (planned to be named LiveScript, renamed for marketing reasons) was born. They borrowed lot of the syntax to please the existing Java programmers and feel familiar to most C-like programmers.

I suggest not to use Error in a Java program. It is intended to be an exception that should not be caught, to signal an unrecoverable problem like out of memory or similar.

GoToLoop

I suggest not to use Error in a Java program. It is intended to be an Exception that should not be caught,...

That's very well explained already in the Error's class description! :-B
However, it's merely a formality! I'm pretty sure Processing framework's take on Java is beyond heresy! >:)

The task at hand here is cross-compatibility between Java & JS modes!
We gotta use what's available, no matter how "wrong" that could be! O:-)

Ucodia

Thanks guys for your answers.

Concerning Processing.js, of course they were not going to implement Java architectural types, it would not make any sense. But we can't get away with the fact that no bridge has been built in between the two frameworks to have real error handling. In fact I am not even sure that Processing has its own exception types or does it?

Using the Error class would be really ugly in the context of a pure Java enterprise application. But when it comes to have a compatible Processing program we don't have much choice, it just has to stay in the context of a Processing program.

In the end, raising this issue to the Processing and Processing.js teams would probably be a good idea.

GoToLoop

In fact I am not even sure that Processing has its own Exception types or does it?

Processing's PApplet class throws mostly RuntimeException, along w/ other common built-in Java 1s:

• ArrayIndexOutOfBoundsException
• IllegalArgumentException
• UnsupportedOperationException

I've spotted a RendererChangeException once, but it's another RuntimeException alias w/ an empty body:
static public class RendererChangeException extends RuntimeException { }

GoToLoop

In the end, raising this issue to the Processing and Processing.js teams would probably be a good idea.

• Processing devs can't do anything b/c they've got nothing to do w/ the conversion that the PJS project does!
• JS only got the Error "class". And that's pretty enough to make custom messages!
• PJS devs could make it smart enough to transpile any Java class w/ the word Exception as Error.
• Unfortunately the PJS project is halted in favor for the new kiddie P5.JS: http://p5js.org.