xpcall message handler error

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

xpcall message handler error

aryajur
Hi,
     I see that if there is an error in the message handler then the program gets stuck and results in a stack overflow. For example:

function f ()
    local y= "a" +   2  -- will cause error
end -- f

function err (x)
    print("err called", x)
    error("Inside message handler")
    return x
end -- err
print (xpcall (f, err))

So if there is a message handler which may throw an error in case of something unexpected then is there any way to control this. One way would be to wrap the message handler inside your own handler and check the stack using the debug library. Is there a better way to do this?

Thanks,
Milind

Reply | Threaded
Open this post in threaded view
|

Re: xpcall message handler error

szbnwer@gmail.com
hi there! :)

ive got a general wrapper for preventing errors in callbacks that are
made inside my protected environment but put down somewhere and that
will be called from codes that are outside of my protected
environment. its a little bit tangled with my app, but the essence
looks like:

```
(function(...)
  if ... then
    print'succ'
    return select(2, ...)
  else
    print'err'
    return select(2, ...) end end)(pcall(f, args))
```
things around this should handle `f` and `args` (u can use both
`unpack()` and  `...` for `args` from an outer function, and u can
handle the error inside the anon function as u like it)

note, that its necessary to capture the return values of `pcall()`
with a function, otherwise (`{...}`) u can only check the number of
the returned args from it, or catch them, but not both... or maybe u
can, but not in 5.1! :D

ask bravely if its necessary, but now i had the mental capacity only
for this much :D

bests, have fun! :)

Reply | Threaded
Open this post in threaded view
|

Re: xpcall message handler error

szbnwer@gmail.com
lol, i just realized that it still wont solve ur problem :D my error
handler could also fail if it wouldnt be ensured more or less that
those will be fine when i reach the point of using this... otoh i
should think about using xpcall after a sleep, maybe its a thing for
me as well! :D

otherwise just make a protected error handler so if u have an error in
that, ull see that, otherwise if it works and u have an error that is
captured by it, then ull see that, but no crash will stop the show

(pro tip: if the protector of ur protector could also fail, then
protect that as well X'D )

my technique is to run a test instance before saving the core of my
app, if that will fail, then ill see the error in the original app,
otherwise it will make the new version of itself permanently saved.
the wrapper that ive talked about is a different beast for protecting
against errors i could make after once its already up and running :D