Bug #26613 for Brick: Fatal errors in brick closures ignored

Tue Apr 24 15:11:03 2007 agianni [...] buffalo.edu - Ticket created

Subject:

Fatal errors in brick closures ignored

Currently, if an otherwise fatal error occurs within a brick closure, the error is not reported and the brick, which might have otherwise failed, returns success. I've spent some time trying to track down how I would patch this myself, but I just keep going around in circles. If you can give me a hint as to where I need to look to deal with this I'd be happy to write the patch.

Tue May 01 18:56:23 2007 bdfoy [...] cpan.org - Correspondence added

On Tue Apr 24 15:11:03 2007, agianni@buffalo.edu wrote: Show quoted text

> Currently, if an otherwise fatal error occurs within a brick closure, > the error is not reported and the brick, which might have otherwise > failed, returns success. I've spent some time trying to track down how I > would patch this myself, but I just keep going around in circles. If you > can give me a hint as to where I need to look to deal with this I'd be > happy to write the patch.

Can you give me an example of something you ran into that causes this problem? Is this something like trying to use a regex that doesn't compile?

Tue May 01 18:56:24 2007 The RT System itself - Status changed from 'new' to 'open'

Wed May 02 15:13:02 2007 agianni [...] buffalo.edu - Correspondence added

Subject:	Re: [rt.cpan.org #26613] Fatal errors in brick closures ignored
Date:	Wed, 02 May 2007 15:11:51 -0400
To:	<bug-Brick [...] rt.cpan.org>
From:	Andrew Gianni <agianni [...] buffalo.edu>

Show quoted text

> On Tue Apr 24 15:11:03 2007, agianni@buffalo.edu wrote:

>> Currently, if an otherwise fatal error occurs within a brick closure, >> the error is not reported and the brick, which might have otherwise >> failed, returns success. I've spent some time trying to track down how I >> would patch this myself, but I just keep going around in circles. If you >> can give me a hint as to where I need to look to deal with this I'd be >> happy to write the patch.

> > Can you give me an example of something you ran into that causes this > problem? Is this something like trying to use a regex that doesn't compile?

Any kind of run time error. In our case, we use some database utilities that do lookups for us but fail fatally under certain circumstances. In almost every case it would be a case of programmer error. Right now, there are cases where data should not validate, but since the fatal error is completely ignored, validation passes anyway. I really would like to be able to throw an error that prevents validation from passing. It needn't be an actually fatal error, perhaps the result object could contain some kind of indicator? Since no field is given when these errors occur, they're ignored when processing the results with flatten_by_field, which is the main problem. Maybe we just need an additional method in Brick::Result that combs through the result hash and mentions if it sees anything but hashrefs in the error entries -- basically a lint for the results hash. This would also work as at least a temporary fix for RT#26729, as I could use this to avoid the "not a HASH ref" error I'm getting when I end up with a coderef in the error entry (still not sure why this happens).

Wed May 02 16:03:16 2007 bdfoy [...] cpan.org - Correspondence added

From:

BDFOY [...] cpan.org

On Tue Apr 24 15:11:03 2007, agianni@buffalo.edu wrote: Show quoted text

> Currently, if an otherwise fatal error occurs within a brick closure, > the error is not reported and the brick, which might have otherwise > failed, returns success. I've spent some time trying to track down how I > would patch this myself, but I just keep going around in circles. If you > can give me a hint as to where I need to look to deal with this I'd be > happy to write the patch.

Okay, I think I know how to do this. What if I catch that problem and make the validation error something like "[Program Error: $@]", then just insert that into the error hash? Now, the trick is, how do you want to handle that with the user display? You don't want to show that to the user, but you want to see it. Something in flatten_* might be able to catch that.

Wed May 09 13:39:17 2007 bdfoy [...] cpan.org - Correspondence added

I'm promoting programming errors caught by eval (so, where $@ is a string) to the hash reference used by the validation errors. The hash ref will have a key for 'program_error'. You won't need to worry about the implementation though because the new Brick::Result::Item class has methods to ask questions about the result.

Tue May 29 17:32:05 2007 bdfoy [...] cpan.org - Correspondence added

This was changed in 0.226_01. Programming errors are now treated as every other error.

Tue May 29 17:32:08 2007 bdfoy [...] cpan.org - Status changed from 'open' to 'resolved'