Mail archive
acf

[Acf] acf - error handling

From: Nathan Angelacos <nangel_at_nothome.org>
Date: Sat, 09 Dec 2006 01:25:33 +0000

From an irc conversation between nangel & ncopa.

How to handle errors in acf?

If cf is an object, and webcf is a child of it,
and model,view,controller are all objects that "try real hard" to send
you to an error controller (e.g. __index points to the "I'm an error"
function")

and if error is a mvc triad just like everything else...

When controller runs into an error, what should it do?

Controller can run into several classes of errors:

        action does not exist
        user is not authorized for action
        model doesn't exist
        model function doesn't exist
        syntax error in application code


ncopa's thought was "raise an error" But how do you determine an
application error from a syntax error? (e.g. "you are not authorized"
is different from the syntax error, where we want to simply say "An
unexpected situation occurred.")


ncopa also suggested running the controller and view as pcalls. Here's
an example of how it could be done:

etable = {}
etable.report = function ( arg )
        io.write("This is etable.report: ")
        if type(arg) == "string" then
                io.write(string.format("Unhandled exception:\n\t%s\n", arg))
        elseif type(arg) == "function" then
                arg()
        elseif type(arg) == "table" then
                print (arg.message)
        else
                print ("Weirdo unhandled exception")
        end

end



myfunc = function ()
        local foo = 3
        print ("Myfunc here!!!")
        --error({ class="ACF error",
                        message="This error is a special ACF message."})
        local b = "a" + 3

end


local status, err = pcall(myfunc)
        if status == false then
                etable.report(err)
        end

<<<<<< SNIP >>>>>>>>>


The above code will run the etable.report and report the syntax error
(as exepected) If you commend out the "error" call, etable.report gets
a table back, rather than a string, and it will handle it differently.

This means it should be possible to send back a table or function to the
error MVC triad, logging the error, printing whatever is necessary, etc.

For the case of code syntax errors, or other LUA errors, a string is
returned, so the error MVC can handle that as a special "unhandled"
situation, and the web app can die gracefully.

--
Received on Sat Dec 09 2006 - 01:25:33 GMT