This is a read-only snapshot of the ComputerCraft forums, taken in April 2020.
Creator's profile picture

Coroutine error handling

Started by Creator, 10 April 2015 - 09:21 PM
Creator #1
Posted 10 April 2015 - 11:21 PM
Hello guys, is there any way to discover what caused a coroutine to crash/die?

Thanks in advance

Creator
KingofGamesYami #2
Posted 10 April 2015 - 11:28 PM
PIL said:
Note that resume runs in protected mode. Therefore, if there is any error inside a coroutine, Lua will not show the error message, but instead will return it to the resume call.

No, but this can be solved by wrapping your function in an error handler, something like this:


coroutine.create( function()
  local ok, err = pcall( func )
  if not ok then
    --#error handling here
  end
end )
Edited on 10 April 2015 - 09:29 PM
wieselkatze #3
Posted 10 April 2015 - 11:34 PM
PIL said:
Note that resume runs in protected mode. Therefore, if there is any error inside a coroutine, Lua will not show the error message, but instead will return it to the resume call.

No, but this can be solved by wrapping your function in an error handler, something like this:

That is not true - coroutine.resume() always returns a success value and a matching second value.
E.g. if you resume a coroutine it could return true, "redstone".
"redstone" in this case would be the filter caused by the coroutine.yield() in your coroutine.
If you use coroutine.yield("key") it'd return true, "key".

If now for whatever reason the coroutine fails to run - e.g. an error, the first value will be false and the matching value will be the error message.
E.g. if you run the following code:


function test()
pritn("hello") --# will error
end

local ok, res = coroutine.resume( coroutine.create( test ) )

print( ok .. ":" .. res )

This would print out the resume result and the error message caused.
"false:attempt to call nil" or sth. like that.
Edited on 10 April 2015 - 09:36 PM
Creator #4
Posted 10 April 2015 - 11:42 PM
PIL said:
Note that resume runs in protected mode. Therefore, if there is any error inside a coroutine, Lua will not show the error message, but instead will return it to the resume call.

No, but this can be solved by wrapping your function in an error handler, something like this:


coroutine.create( function()
  local ok, err = pcall( func )
  if not ok then
	--#error handling here
  end
end )

Thanks.

Did you get my message?

PIL said:
Note that resume runs in protected mode. Therefore, if there is any error inside a coroutine, Lua will not show the error message, but instead will return it to the resume call.

No, but this can be solved by wrapping your function in an error handler, something like this:

That is not true - coroutine.resume() always returns a success value and a matching second value.
E.g. if you resume a coroutine it could return true, "redstone".
"redstone" in this case would be the filter caused by the coroutine.yield() in your coroutine.
If you use coroutine.yield("key") it'd return true, "key".

If now for whatever reason the coroutine fails to run - e.g. an error, the first value will be false and the matching value will be the error message.
E.g. if you run the following code:


function test()
pritn("hello") --# will error
end

local ok, res = coroutine.resume( coroutine.create( test ) )

print( ok .. ":" .. res )

This would print out the resume result and the error message caused.
"false:attempt to call nil" or sth. like that.

Hey, thanks. Here, get a +1 and a potato. POTATO
Lyqyd #5
Posted 11 April 2015 - 12:11 AM
PIL said:
Note that resume runs in protected mode. Therefore, if there is any error inside a coroutine, Lua will not show the error message, but instead will return it to the resume call.

No, but this can be solved by wrapping your function in an error handler, something like this:


coroutine.create( function()
  local ok, err = pcall( func )
  if not ok then
    --#error handling here
  end
end )

Did you read the paragraph in the PIL you quoted? You should read through the implementation of pcall in the ComputerCraft bios.
KingofGamesYami #6
Posted 11 April 2015 - 01:45 AM
Well this is embarrassing, especially considering that's how I thought it worked - I looked it up in the PIL to make sure. *facepalm*