René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Compiler errors become useless as soon as you have another PApplet","articleBody":"_Original author: pinter.f...@gmail.com (December 31, 2011 06:50:51)_\n\nOnce you have another PApplet defined, Any syntax error (e.g. a stray character or missing semicolon), gets reported as \u0026quot;unexpected void\u0026quot; on the setup.  Meaning it becomes laborious to find even the simplest syntax error -- involving going through all the code commenting and uncommenting blocks until the error goes away.  And doing this every time a new syntax error is introduced.\n## To see simply, first:\n\nvoid setup()\n{\n    int a=0;\n}\nvoid draw()\n{\n    int b=0;\n    *\n## }\n## Note the '*' is there intentionally.  When you run, you get a nice error showing just where the problem is.  Now add a couple lines:\n\nvoid setup()\n{\n    int a=0;\n}\nvoid draw()\n{\n    int b=0;\n    *\n}\n\npublic class newApp extends PApplet {\n## }\n\nSuddenly this error (and any other you might introduce) are all reported as unexpected void in setup.\n\n_Original issue: http://code.google.com/p/processing/issues/detail?id=952_\n","author":{"url":"https://github.com/processing-bugs","@type":"Person","name":"processing-bugs"},"datePublished":"2013-02-10T17:09:50.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":4},"url":"https://github.com/990/processing/issues/990"}