Loading ...
Sorry, an error occurred while loading the content.

Re: [fusebox5] Handling model errors before they become display errors in MVC fusebox

Expand Messages
  • DEREK HEDSTROM
    Thanks for the reply Erik.  I do have several error handlers defined to give similar control over catching errors much like you describe. The question has
    Message 1 of 4 , Feb 13, 2013
    • 0 Attachment
      Thanks for the reply Erik.

       I do have several error handlers defined to give similar control over catching errors much like you describe.

      The question has more to do with the architecture of the application, and after thinking it over, I've decided that there really isn't any way to use error handlers in order to make this happen automatically. Whatever happens there always needs to be a condition of some sort explicitly set to indicate these types of errors. I've decided that this process best belongs in the Model and is checked in the controller prior to calling the relevant display fuseactions.

      While they are good for what they are designed for, error handlers are 'cross cutting' and don't fit the process involved well enough to use for this.

      Anyway, I appreciate your input.


      ----- Original Message -----
      From:
      fusebox5@yahoogroups.com

      To:
      <fusebox5@yahoogroups.com>
      Cc:

      Sent:
      Tue, 12 Feb 2013 18:51:11 -0800
      Subject:
      Re: [fusebox5] Handling model errors before they become display errors in MVC fusebox




      How about his in Application.cfm

      <cferror type="request" template="wherever/error.cfm">

      -Erik

      On Mon, Dec 17, 2012 at 3:50 PM, GCI <derekhedstrom@...> wrote:
       

      Greetings,

      I have been using Fusebox for quite a while now and am looking for advice on improving my process of handling errors in the model before they become errors in the display. Typically, I want to avoid undefined variable errors when a database query fails and instead display a nice custom message to the user.

      Bear with me and I'll try and explain this as best I can.

      I've created 4 error handlers (Application, DB, Expression, and Validation) and registered them in the fusebox.xml file's 'fuseactionException' plugin phase. These are all set to email the webmaster when called and provide details of the problem. They also set a general error message to be displayed to the user.

      In pseudocode, here's my typical process:
      1. Controller calls a model template and let's say it fails because the database is down.
      2. Because this is a DB error, the Database error handler defined in my plugins section jumps to the rescue. It sets a handy-dandy boolean called 'SUCCESS' to FALSE, sets a nice friendly error message and finally sends an email to the webmaster with the error details contained in the cfcatch structure.
      3. In the root circuit's post Fuseaction, a check of SUCCESS is made, and if it's FALSE, it over-writes the content created by all the display templates up to that point with the friendly error message from the error handler, then finally calls the layout and returns the page.

      What I'd like to do is remove the use of the SUCCESS boolean. This is how it's typically used in the controller circuit.xml file:
      <fuseaction name="home">
        ..
        <do action="m.qryGetAllRecords" />
        <if condition="SUCCESS EQ TRUE">
          <true>
            <do action="v.dspHome" contentvariable="content.main" />
          </true>
        </if>
      </fuseaction>

      Eventually I'd like the controller to read like this:
      <fuseaction name="home">
        <do action="m.qryGetAllRecords" />
        <do action="v.dspHome" contentvariable="content.main" />
      </fuseaction>

      To do this, I need a way to suppress further triggering of the other error handlers caused by the broken database, but I'd like to do this without resorting to boolean 'flags'. Whatever system is used, I'd like it to also handle errors intentionally thrown by the model due to missing/bad search parameters (IDs that are missing, incorrect or out-of-bounds, etc.) because in these cases I really don't need an email sent to me by the other error handlers just because someone forgot to enter a search term.

      What are other folks doing to provide custom error messages regarding model errors while still avoiding display errors?

      I am using MVC and the XML version of FB 5.5.1

      TIA,
      Derek Hedstrom
      ======
      He who knows not and knows that he knows not is ignorant.  Teach him.
      He who knows not and knows not that he knows not is a fool.  Shun him.
      He who knows and knows not that he knows is asleep.  Wake him.







    • sommers.steve@rocketmail.com
      I all but exclusively use application.cfc instead of application.cfm and defaine an onError function. For some reason is seems more reliable than using
      Message 2 of 4 , Feb 13, 2013
      • 0 Attachment
        I all but exclusively use application.cfc instead of application.cfm and defaine an onError function. For some reason is seems more reliable than using cferror:

        <cffunction name="onError" returntype="void" output="true" access="public" hint="I am executed when an unhandled error occurs">
        <cfargument name="exception" type="any" required="true" />
        <cfargument name="eventName" type="string" required="true" />

        <cfset local.template = "error.cfm" />
        <cfset request.exception = arguments.exception />
        <cfif isDefined("arguments.exception.cause.message") AND listFindNoCase("undefined Circuit,undefined Fuseaction,malformed Fuseaction", arguments.exception.cause.message)>
        <cfif isDefined("variables.attributes.fuseaction") and listFindNoCase("ota,htng",listFirst(variables.attributes.fuseaction,"."))>
        <cfset request.errorObj = arguments.exception />
        <cfinclude template="model/m_ota/act_handleError.cfm" />
        <cfset variables.error.type = "invalid4ResAction" />
        <cfset variables.error.message = "Invalid FA value or malformed request." />
        <cfset variables.error.docURL = "http://www.shift4.com/dotn/4Res/apiErrors.cfm?code=#variables.error.code#.#variables.error.type#" />
        <cfset local.template = "view/v_ota/dsp_proxyError.cfm" />
        <cfelse>
        <cfheader statuscode="404" statustext="Not Found" />
        <!--- show 404 page or could redirect --->
        <cfset variables.errMsg = "Oops! Page not found." />
        </cfif>
        </cfif>
        <cfoutput><cfinclude template="#local.template#" /></cfoutput>
        </cffunction>


        --- In fusebox5@yahoogroups.com, Erik Voldengen wrote:
        >
        > How about his in Application.cfm
        >
        >
        >
        > -Erik
        >
        > On Mon, Dec 17, 2012 at 3:50 PM, GCI wrote:
        >
        > > **
        > >
        > >
        > > Greetings,
        > >
        > > I have been using Fusebox for quite a while now and am looking for advice
        > > on improving my process of handling errors in the model before they become
        > > errors in the display. Typically, I want to avoid undefined variable errors
        > > when a database query fails and instead display a nice custom message to
        > > the user.
        > >
        > > Bear with me and I'll try and explain this as best I can.
        > >
        > > I've created 4 error handlers (Application, DB, Expression, and
        > > Validation) and registered them in the fusebox.xml file's
        > > 'fuseactionException' plugin phase. These are all set to email the
        > > webmaster when called and provide details of the problem. They also set a
        > > general error message to be displayed to the user.
        > >
        > > In pseudocode, here's my typical process:
        > > 1. Controller calls a model template and let's say it fails because the
        > > database is down.
        > > 2. Because this is a DB error, the Database error handler defined in my
        > > plugins section jumps to the rescue. It sets a handy-dandy boolean called
        > > 'SUCCESS' to FALSE, sets a nice friendly error message and finally sends an
        > > email to the webmaster with the error details contained in the cfcatch
        > > structure.
        > > 3. In the root circuit's post Fuseaction, a check of SUCCESS is made, and
        > > if it's FALSE, it over-writes the content created by all the display
        > > templates up to that point with the friendly error message from the error
        > > handler, then finally calls the layout and returns the page.
        > >
        > > What I'd like to do is remove the use of the SUCCESS boolean. This is how
        > > it's typically used in the controller circuit.xml file:
        > >
        > > ...
        > >
        > >
        > >
        > >
        > >
        > >
        > >
        > >
        > > Eventually I'd like the controller to read like this:
        > >
        > >
        > >
        > >
        > >
        > > To do this, I need a way to suppress further triggering of the other error
        > > handlers caused by the broken database, but I'd like to do this without
        > > resorting to boolean 'flags'. Whatever system is used, I'd like it to also
        > > handle errors intentionally thrown by the model due to missing/bad search
        > > parameters (IDs that are missing, incorrect or out-of-bounds, etc.) because
        > > in these cases I really don't need an email sent to me by the other error
        > > handlers just because someone forgot to enter a search term.
        > >
        > > What are other folks doing to provide custom error messages regarding
        > > model errors while still avoiding display errors?
        > >
        > > I am using MVC and the XML version of FB 5.5.1
        > >
        > > TIA,
        > > Derek Hedstrom
        > > ======
        > > He who knows not and knows that he knows not is ignorant. Teach him.
        > > He who knows not and knows not that he knows not is a fool. Shun him.
        > > He who knows and knows not that he knows is asleep. Wake him.
        > >
        > >
        > >
        > >
        > >
        > >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.