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

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

Expand Messages
  • 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 1 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.