Error: Java Exception Thrown

While I'm an experienced programmer, I've never done anything with networking or lua.

I have here a very small script that deals with both (obviously), and predictibly, I'm unable to make the darn thing work. The most interesting bit of trouble I'm having is this Java error -See I was under the impression we were using lua. o.o So I'm very curious about that.

I'll put the script up as is for the java error (again, the most interesting problem I've run into). Before that though, I'll provide a breif description of the programs purpose and desired behavior. And if any of you can tell me how to get the darn thing to work I'd be most appreciative.

-The program is called "receive". It's purpose is to collect gps information from a portable device at regular intervals of fractions of a second, and display the information on a monitor.

while true do
peripheral.call("back", "clear")
peripheral.call("back", "setCursorPos", 1, 1)
a, b, c = rednet.receive() --for each axis
peripheral.call("back", "write", a)
peripheral.call("back", "write", B)/>/>
peripheral.call("back", "write", c)
end

And the broadcasting script

while true do
a, b, c = gps.locate()
rednet.broadcast(a..b..c)
term.clear()
term.setCursorPos(1,1)
print(a.."|"..b.."|"..c)
end

Java exceptions are not actual bugs - they won't happen if your script is written correctly.

In this case, you are giving peripheral.call invalid arguments. rednet.recieve() returns id, message. a, b, c = id, message, nil

a = id
b = a|b|c
c = nil

This causes problems when passed to peripheral.call("back", "write", "a|b|c|")

KingofGamesYami, on 22 February 2015 - 10:52 PM said:

Java exceptions are not actual bugs - they won't happen if your script is written correctly.

I'd call them bugs - problems like this should never get as far as causing a Java-side error, they should be caught and a proper Lua-based error should be provided instead. Problems that need to be "triggered" are still problems. This code wouldn't've thrown this error prior to CC 1.6.

Of course, because not all peripheral authors will feel like catching them, the actual Java error is still more useful than this "Java exception thrown" nonsense. Thus it irks me on two levels.

Either way, it's not a CC bug as such. Moved to Ask a Pro.

Lyqyd: It sounds like a bug to me. No built-in peripheral should be throwing java exceptions at it's users. Anybody got a reproduction case?

As an aside: In CC1.7, the type and message of the java exception is retained in the Lua error raised, for better diagnosis of this-thing-that-should-not-happen.

Update:
I've fixed the bug. Monitor.write() was checking for the existence of a parameter, but not whether it was null or not.

Yes, I see the errors are improved under 1.7. That's good! :)/>

As for reproduction, just make like the example at the top of the thread here and try to call a monitor's "write" function with nil as the parameter. Eg:

peripheral.call("top","write",nil)

Again, I believe this started with 1.6. "Works" under 1.5whatever, in that it doesn't throw an error but rather just doesn't write anything.

While on the topic, if you try to write nil to an open file handle, same thing. Also, and this might be a bit trickier to deal with, multishell causes errors due to bad term calls to appear to come from the window API (eg, try term.setCursorPos() with invalid arguments - the window API gets blamed, not the offending script).

As I mentioned in the last post, monitor.write() would work, but monitor.write(nil) would not. These would normally be equivalent, but due to an error in the code, they weren't. The code in question was as old as monitors themselves.

Whoops, I somehow glossed over the peripheral in question being a monitor! That would indeed put this firmly in the realm of ComputerCraft bugs. My mistake.

Same Problem by Version 1.72
the logisticpipes API for computercraft doesn't work and when things works. I get a Java exeption thrown

Please post the code you are using. ComputerCraft does not, as far as I know, provide a peripheral interface for the logistics pipes.

Closing this thread as the bug in question has now been fixed