lua-users home
lua-l archive

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

I realize that I never actually answered the question, just how I *represent* an error that is caused by this. The `IOError()` class has an `errstr` and `errnum` value that are assigned by the first and second value when calling `IOError()`; This is passed to `error()` and unless caught exits.

On Sun, Mar 5, 2017 at 11:56 PM Charles Heywood <> wrote:
I'm rewriting some of the Lua standard library for FusionScript, and when working with "silent" errors, I decided to take the Lua error triplet - nil, string, number - and convert it into a special class called IOError. This was risen by error() to fatally halt the script if not handled. I personally thought that if there's an IO error, then there's probably something wrong with your program - or you forgot to use a Try() lambda.

I know that some poeple use `` as a way to check if a file exists, and since LuaFileSystem is already required for the compiler, which means it's installed by default with the runtime, i just leave users to check `lfs.attributes()` on a file.

On Sun, Mar 5, 2017 at 11:50 PM Sean Conner <> wrote:
It was thus said that the Great David Favro once stated:
> On 03/05/2017 06:40 PM, Xavier Wang wrote:
> >It should be:
> >
> >assert("results.txt","w")):write(table.concat(results,"\n")):close()
> >
> >when you use in production code.
> This should *not* be used in production since it does not check for error
> return from file:write() or file:close().  Try this:
> assert(assert(assert("results.txt","w")):write(table.concat(results,"\n"))):close());
> See also:
> This is precisely why exceptions were created, because most (i.e. nearly
> all) programmers do not properly handle errors when they are mixed into the
> data channel of the return-value.  It was always a favorite parlor game of
> mine, when I encounter a C programmer who insists that he checks for errors
> in the return-value of _every_ function call that he makes, to show me all
> of his printf()s and fprintf()s.  I've not lost that bet yet.

  Years ago when I was back in college, I was writing a program whose main
use was to run unattended.  Yes, I could log errors to the screen (or
console if you will) but being an unattended program, it won't be noticed.
So I decided to log any errors to a file.  But what if I couldn't log to the
disk?  Well, I could log to the printer, but there might not be a printer,
or it might be out of paper or otherwise not available.  And that's where I
got stuck.

  Now, being in college, I decided to ask the wisdom of a 30 year IBM
veteran (who worked on the original Fortran compiler if I'm not mistaken)
and was now an instructor what I should do.  And his answer stunned me:  "If
you don't know how to handle an error, you shouldn't check for it."

  In the years since, I've come to accept the wisdom of that advice, as odd
as it sounds.

  So my question to you is---how do *you* handle a failed printf() call?

  -spc (Just curious ... )


Software Developer / System Administrator

Ryan <>
Software Developer / System Administrator