lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]



On Thu, Sep 18, 2014 at 1:22 PM, Tim Hill <drtimhill@gmail.com> wrote:
It really comes down to “where is the code that handles this condition?”. If it’s close to the code that caused it, then the whole apparatus of exceptions or pcalls() is just an ornate way of returning an error code from the callee to the caller. If it’s far away, then you WANT an exception model so that you can avoid the absurd “ripple through” model where error codes have to be returned up a winding call stack.

And yes, there are some nasty examples that sit right in the middle, which is why everyone argues for hours about stuff like this :)

I like to hear this point again, because the various was that it is stated helps enforce things in my brain. I'm at: "Error handling is hard" which puts me in pretty decent company.

I agree with your points and Dirks, which are applicable everywhere, as you've said[1].

My point is that the two methods of `nil, err_str` and `success, retval = pcall(fun, ...)` are difficult to manage simultaneously, when one function call may result in either error style. A function can say "returns nil, error if it failed to do what you asked" in its documentation, but  mistakes happen, many Lua standard functions call error on bad input and as a result, you never know. Using `pcall` for garden variety stuff like missing files is pretty easy to do, so..meh?

Across message passing boundaries, I'll fail nicely with an error message. But internally and to people using my library through Lua, I'm gonna explode with an error and let them decide what to do with it.

If it doesn't work out, I'll invent some other method, and then realize that I've accidentally invented a poor-quality replacement for `nil, err_str`.

-Andrew




[1] Someone linked to an article on the D programming language, and I thought that was interesting.