[Mason-devel] Exception handling changes redux

[Dave Rolsky]

I just checked in a change to add a new Request parameter,
errors_are_exceptions. By default, this is true, and Mason behaves the
same way as always. If you set this to false, then Mason will not set a
$SIG{__DIE__} handle when compiling or running components.

I'm not entirely thrilled about the name, so if people have better ideas
please let me know. But please let me know soon because I'd like to
release 1.36 in the near future.


-dave

/*===================================================
VegGuide.Org www.BookIRead.com
Your guide to all that's veg. My book blog
===================================================*/

[Jonathan Swartz]

Yeah, that name is a bit odd.

What about

process_runtime_errors => (CODE | false)

By default this has the current behavior. If given a code reference,
will call that with $@ in the $SIG{__DIE__} handle to process the
runtime error. If given a false value, will leave runtime errors alone.

Jon

Post by Dave Rolsky
I just checked in a change to add a new Request parameter,
errors_are_exceptions. By default, this is true, and Mason behaves the
same way as always. If you set this to false, then Mason will not set a
$SIG{__DIE__} handle when compiling or running components.
I'm not entirely thrilled about the name, so if people have better ideas
please let me know. But please let me know soon because I'd like to
release 1.36 in the near future.
-dave
/*===================================================
VegGuide.Org www.BookIRead.com
Your guide to all that's veg. My book blog
===================================================*/
----------------------------------------------------------------------
---
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Mason-devel mailing list
https://lists.sourceforge.net/lists/listinfo/mason-devel

[Dave Rolsky]

Post by Jonathan Swartz
What about
process_runtime_errors => (CODE | false)

That name might be a bit confusing too. This isn't a general runtime
thing, it's specific to the compilation & execution of components. Maybe
"component_error_handler"?


-dave

/*===================================================
VegGuide.Org www.BookIRead.com
Your guide to all that's veg. My book blog
===================================================*/

[Jonathan Swartz]

Post by Dave Rolsky

Post by Jonathan Swartz
What about
process_runtime_errors => (CODE | false)

That name might be a bit confusing too. This isn't a general
runtime thing, it's specific to the compilation & execution of
components. Maybe "component_error_handler"?

Doesn't it affect anything called from components as well, that is,
anything down the stack from the initial interp exec()? In that case,
component_error_handler seems more confusing.

Jon

[Dave Rolsky]

That name might be a bit confusing too. This isn't a general runtime thing,
it's specific to the compilation & execution of components. Maybe
"component_error_handler"?

Doesn't it affect anything called from components as well, that is, anything
down the stack from the initial interp exec()? In that case,
component_error_handler seems more confusing.

Well, it's errors that happen when running a component, regardless of
source. It makes sense to me, but I'm open to better names. I think tha
name should end in "handler", since that is a common name for sub
reference like this.


-dave

/*===================================================
VegGuide.Org www.BookIRead.com
Your guide to all that's veg. My book blog
===================================================*/

[Jonathan Swartz]

Post by Dave Rolsky

Post by Dave Rolsky
That name might be a bit confusing too. This isn't a general
runtime thing,
it's specific to the compilation & execution of components. Maybe
"component_error_handler"?

Doesn't it affect anything called from components as well, that is, anything
down the stack from the initial interp exec()? In that case,
component_error_handler seems more confusing.

Well, it's errors that happen when running a component, regardless of
source. It makes sense to me, but I'm open to better names. I think tha
name should end in "handler", since that is a common name for sub
reference like this.

Ok, why don't we compromise on "runtime_error_handler". :)

This *is* a general runtime thing, in that any runtime error that
occurs within a Mason request will be affected by it. Mason
components can call subroutines and methods to get data, etc., and
errors that occur there will be affected by this.

Jon

[Dave Rolsky]

Post by Jonathan Swartz
Ok, why don't we compromise on "runtime_error_handler". :)
This *is* a general runtime thing, in that any runtime error that occurs
within a Mason request will be affected by it. Mason components can call
subroutines and methods to get data, etc., and errors that occur there will
be affected by this.

Are you suggesting that we should _not_ use this handler when compiling
the component? Right now we set $SIG{__DIE__} in two methods of Request.
One is exec, but the other is _initialize. The latter is effectively the
component compilation stage, since it's when we create or load the parsed
Perl of a component.


-dave

/*===================================================
VegGuide.Org www.BookIRead.com
Your guide to all that's veg. My book blog
===================================================*/