Jump to content




[SOLVED] pcall calling


  • You cannot reply to this topic
8 replies to this topic

#1 unobtanium

  • Members
  • 505 posts

Posted 01 March 2014 - 03:51 PM

Well, hello, its me again :S

Since i am working on the "Client for OpenPeripheral's Glasses" i am calling methods with the
.callRemote(<peripheral>, <function>)
function.
It is also possible to call arguments with
.callRemote(<peripheral>, <function>, unpack(<argument_table>))

The problem is that the possibility exists that the player didnt put the correct amount or type of arguments in.
I now wanted the program to detect this and tried it with pcall(), but that didnt worked for me at all.

Is there a solution for such an error handling? Maybe i did something wrong with pcall?

Thanks
unobtanium

Edited by UNOBTANIUM, 01 March 2014 - 04:36 PM.


#2 CometWolf

  • Members
  • 1,283 posts

Posted 01 March 2014 - 04:08 PM

Since you can't pass arguments to the function called by pcall, it would have to be something like this
local noErr,res = pcall(
  function()
    peripheral.callRemote(name,func,args)
  end
)
if noErr then
  --sucessfull
  print(res) --return values
else
  --error
  print(res) --error message
end
I would need to see your actual code before i can give you any more help than that.

#3 unobtanium

  • Members
  • 505 posts

Posted 01 March 2014 - 04:15 PM

Thank you very much. That did the job :)

#4 MKlegoman357

  • Members
  • 1,170 posts
  • LocationKaunas, Lithuania

Posted 01 March 2014 - 06:55 PM

I think it would be better to just check what variables are passed to your function:

function test (name, age)
  if type(name) ~= "string" then error("Name must be a string!", 2) end
  if type(age) ~= "number" then error("Age must be a number!", 2) end
end


#5 theoriginalbit

    Semi-Professional ComputerCrafter

  • Moderators
  • 7,332 posts
  • LocationAustralia

Posted 01 March 2014 - 11:51 PM

Hey unobtanium,

I know you've got this solved, but it's time for a correction to be made...

View PostCometWolf, on 01 March 2014 - 04:08 PM, said:

Since you can't pass arguments to the function called by pcall
ummmmm..................

local ok, err = pcall(peripheral.callRemote, name, func, unpack(args))

if not ok then
  print(err)
end

Edited by theoriginalbit, 01 March 2014 - 11:52 PM.


#6 unobtanium

  • Members
  • 505 posts

Posted 02 March 2014 - 02:35 AM

View PostMKlegoman357, on 01 March 2014 - 06:55 PM, said:

I think it would be better to just check what variables are passed to your function:

function test (name, age)
  if type(name) ~= "string" then error("Name must be a string!", 2) end
  if type(age) ~= "number" then error("Age must be a number!", 2) end
end

I accually cant do this because i might dont know the type of the argument i need :D It is for a client application and i can't tell which method has which arguments (i could in some parts, but not all). So i just need a simple error handling which doesnt let the program crash instantly.

View Posttheoriginalbit, on 01 March 2014 - 11:51 PM, said:

- snip -

local ok, err = pcall(peripheral.callRemote, name, func, unpack(args))

if not ok then
  print(err)
end

Oh, well that makes kinda sense ^^ It also gives a bit more overview. Does it have any improvement over the other version or is it just an other version and i accually doesn't matter?

#7 theoriginalbit

    Semi-Professional ComputerCrafter

  • Moderators
  • 7,332 posts
  • LocationAustralia

Posted 02 March 2014 - 02:56 AM

View PostUNOBTANIUM, on 02 March 2014 - 02:35 AM, said:

Oh, well that makes kinda sense ^^ It also gives a bit more overview. Does it have any improvement over the other version or is it just an other version and i accually doesn't matter?
well other than the fact that the way CometWolf did it with an anonymous function is pointless — since pcall does support arguments — it does add another function call onto the call stack. Other than that though, functionally it doesn't change how it works, it just adds another layer of abstraction.

The moral though is that pcall does allow for arguments, anything supplied to it after the first argument (which must be a function pointer) will become an argument when it invokes said supplied function.

#8 CometWolf

  • Members
  • 1,283 posts

Posted 02 March 2014 - 11:59 AM

aaah, i was not aware of this. good to know.

#9 theoriginalbit

    Semi-Professional ComputerCrafter

  • Moderators
  • 7,332 posts
  • LocationAustralia

Posted 02 March 2014 - 12:02 PM

View PostCometWolf, on 02 March 2014 - 11:59 AM, said:

aaah, i was not aware of this. good to know.
I figured you didn't given your answer. Hence my correction :)





3 user(s) are reading this topic

0 members, 3 guests, 0 anonymous users