Error handling for FW/1 unhandled paths

[Stu]

Hi,

I'm gradually migrating a legacy app to FW/1.

The legacy .cfm pages are listed in variables.framework.unhandledPaths until they are ported over.

But I've just realised that this means global/application-level exception handling will not fire for these paths. FW/1 deletes the onError handler for unhandled paths.

Any suggestions for catching these kinds of errors?

Thanks!

Stu

[Sean Corfield]

On Wed, Mar 21, 2012 at 3:06 AM, Stu <stu....@gmail.com> wrote:
> But I've just realised that this means global/application-level exception
> handling will not fire for these paths. FW/1 deletes the onError handler for
> unhandled paths.

Correct. The assumption is that if FW/1 doesn't handle a request, FW/1
should not be responsible for error handling.

> Any suggestions for catching these kinds of errors?

How does the legacy app handle errors today?
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

[Stu]

Hi Sean,

The legacy app handled uncaught excpetions in App.cfc's onError().

It's a fairly big site so rather than wait to get everything ported over to FW/1, we've converted App.cfc to FW/1 and marked the old paths as unhandled.

Because FW/1 allows us to override the CF lifecycle methods like onRequestStart and onSessionStart, we can share some common functionality between the unhandled and FW/1 paths.

I'm sure this hybrid approach is fairly non-standard, but it has been really helpful to have FW/1 allow us to flag unhandled paths and still leave the App.cfc methods intact.

As a patch, when an unhandled path hits onRequestStart I've added an old-school <cferror> tag. Feels like a step backwards but might be good enough for this interim, hybrid phase.

Thanks,

Stu

On Wednesday, 21 March 2012 22:53:53 UTC, Sean Corfield wrote:

[Sean Corfield]

Hmm, can you open a ticket on github and I'll have a think about how
best to handle this (probably provide a way to swap in a "legacy"
onError() handler instead of deleting it for unhandled paths).

Sean

[Sam Farmer]

I have a similar set up, Stu, and this is what I did:

void function onRequestStart(string pageRequested){

  //Overriding the FW/1 onRequestStart and calling it only if this is a request for FW/1

  if ( arguments.pageRequested == "/index.cfm" ) {

super.onRequestStart( targetPath=arguments.pageRequested );

  } else {

  //This request is not using FW/1 and we should delete onRequest so it doesn't run.

  structDelete(this, 'onRequest');

structDelete(variables, 'onRequest');

  }

This leaves the onError function in which has all our custom error handling stuff.

--
FW/1 on RIAForge: http://fw1.riaforge.org/

FW/1 on github: http://github.com/seancorfield/fw1

FW/1 on Google Groups: http://groups.google.com/group/framework-one

[Stu]

Issue opened: https://github.com/seancorfield/fw1/issues/121

Thanks again Sean!

Stu

On Thursday, 22 March 2012 20:38:12 UTC, Sean Corfield wrote:

Hmm, can you open a ticket on github and I'll have a think about how
best to handle this (probably provide a way to swap in a "legacy"
onError() handler instead of deleting it for unhandled paths).

Sean

[Stu]

Thanks Sam - that's a good idea. I think I'll proceed with something like this.

Thanks again!

Stu

On Thursday, 22 March 2012 20:47:57 UTC, Sam Farmer wrote:

I have a similar set up, Stu, and this is what I did:

void function onRequestStart(string pageRequested){

  //Overriding the FW/1 onRequestStart and calling it only if this is a request for FW/1

  if ( arguments.pageRequested == "/index.cfm" ) {

super.onRequestStart( targetPath=arguments.​pageRequested );

  } else {

  //This request is not using FW/1 and we should delete onRequest so it doesn't run.

  structDelete(this, 'onRequest');

structDelete(variables, 'onRequest');

  }

This leaves the onError function in which has all our custom error handling stuff.

On Thu, Mar 22, 2012 at 3:38 PM, Sean Corfield wrote:

Hmm, can you open a ticket on github and I'll have a think about how
best to handle this (probably provide a way to swap in a "legacy"
onError() handler instead of deleting it for unhandled paths).

Sean

[Sean Corfield]

The only problem with that is when you need to share application setup
between FW/1 and the "unhandled" code. By not running onRequestStart()
/ onRequest() you may run into problems if the first request to your
application is not for FW/1. Edge case but worth considering.

Sean