Re: behaviour of assert on non-string errors

[Dirk Laurie <dirk.laurie@...>]

2014/1/18 Justin Cormack <justin@specialbusservice.com>:
> On Sat, Jan 18, 2014 at 9:59 AM, Dirk Laurie <dirk.laurie@gmail.com> wrote:
>> 2014/1/18 Peng Zhicheng <pengzhicheng1986@gmail.com>:
>>
>>> IMHO, `assert' and `error' have quite different semantics and use cases.
>>
>>> So, it is quite reasonable for me that `assert' only accept a string
>>> message, since it is to give the (interactive session) user some clue
>>> about what went wrong, instead of to give `pcall' the `error object' to
>>> examine (and maybe to retry or recover) in a programamtic way,
>>> in which case `error' should be used.
>>
>> +1
>>
>
> But but, that means you have to rewrite your code to only use string
> errors not error tables? The whole point is that it fails to give you
> any clue as it just gives an error about the error not being a string,
> when the error has a perfectly good __tostring method that will give
> you a helpful result if called.
>
> Non string error returns are incredibly useful in making a nice
> interface. It is exactly the interactive case where the fact assert
> does not call __tostring is most annoying.
>
> Justin
>

I think you are missing Peng Zhicheng's point, which can be
paraphrased as:

Programs have two kinds of errors:
   1. Bugs. When detected, use assert() with its blunt and brutal stop.
   2. User errors. When detected, use error() with all its flexibility.

I.e. the following code is bad:

n=io.read()
assert(tonumber(n),"you did not enter a valid number")

You should have been using error().

The following code is good:

assert(heap,"Program error: heap has not been initialized.")