[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: [ANN] Lua 5.3.0 (final) now available
- From: Tom N Harris <telliamed@...>
- Date: Wed, 14 Jan 2015 15:49:29 -0500
On Wednesday, January 14, 2015 02:14:01 PM Andrew Starks wrote:
> Do people to to conceive of think of "error" as something dire and to be
> avoided always?
We seem to be under the assumption that pcall is a very expensive operation,
so yes it's frequently avoided. Perhaps in cases when it shouldn't be as well.
I just ran an overly simple test and pcall was at worst 7.8% slower. And that
was an outlier, it was typically closer to 2%. I could've sworn previous
testing showed it to be much worse.
Maybe the aggravation is pcall forces you to check the success value. But
that's similar to the aggravation of having to fasten your seat belt every
time you get in a car. It's a minor annoyance, but the one time you should be
checking for error yet forget to will be a major annoyance.
If library writers are eschewing throwing errors to not inconvenience users
who aren't properly using pcall, then that contributes to the problem. Being
more assertive (pun intended) will drag people kicking and screaming into
proper defensive programming techniques.
Would elevating 'pcall' and 'error' to keywords instead of functions make it
less scary? While we're at it how about 'assert' so we can write expressions
that are only evaluated when the assertion fails?
Then we could stop returning errors as nil,message and just throw exceptions.
Another way to encourage this is to have a standard error format that can be
reliably caught or re-thrown. The simplest would be to write error messages as
"error name: details". Anything else like errors made of two strings, tables,
or a new Exception type I think are unnecessarily complicated.
--
tom <telliamed@whoopdedo.org>