[Changeset] Fcellfun problem with ErrorHandler access to message/id and count..
David Bateman
David.Bateman at motorola.com
Mon Jul 28 04:07:05 CDT 2008
The Fcellfun function has the capability of defining an ErrorHandler
function that addresses any errors that occur in the main function. This
error handler is passed the same arguments as the main function but
prepended with a structure containing the last error message, id and the
cell array index at which the error occurred. Thomas Treichl pointed out
to me that in both 3.0.1+ and 3.1.51+ the prepended value is incorrect.
Firstly the index that is passed is zero based, when in should be
one-based, and so we have to add one to the count value in the prepended
structure. Secondly it appears that the error message and id strings
that are passed are empty. The way these messages are currently
generated is to call Flasterr and get the strings from this call. The
reason it was done this way previous is, if I remember correctly, that
John didn't want to expose the Vlast_error_message and Vlast_error_id
variables to be changed outside of the error.cc file. I'm not sure why
the call to lasterr doesn't work, but suggest that we add a few
functions to access the Vlast_error_message and Vlast_error_id variables
without allowing the variables to be changed, as this would be faster
than having to call the lasterr function through feval.
I therefore suggest the attached patch for 3.1.51+.. With this change I
see the following
function n = myhand (S, varargin)
> disp (S);
> n = NaN;
> endfunction
octave:2>
octave:2> cellfun(@factorial,{-1,3},'ErrorHandler', at myhand);
{
identifier =
message = factorial: n must all be nonnegative integers
index = 1
}
octave:3> lasterror ()
ans =
{
message = factorial: n must all be nonnegative integers
identifier =
stack =
{
file =
/home/adb014/octave/code/octave-build/../octave-hg/scripts/specfun/factorial.m
name = factorial
line = 32
column = 5
}
}
Unfortunately unless we can figure out why the lasterr call didn't work
I see no fix for 3.0.1+ that doesn't alter the error.h file and thus the
3.0.x API which we want to keep unaltered. So maybe this is a bug that
won't be fixed in 3.0.x.
Regards
David
--
David Bateman David.Bateman at motorola.com
Motorola Labs - Paris +33 1 69 35 48 04 (Ph)
Parc Les Algorithmes, Commune de St Aubin +33 6 72 01 06 33 (Mob)
91193 Gif-Sur-Yvette FRANCE +33 1 69 35 77 01 (Fax)
The information contained in this communication has been classified as:
[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch8357
Url: https://www.cae.wisc.edu/pipermail/bug-octave/attachments/20080728/144d88d5/attachment-0001.ksh
More information about the Bug-octave
mailing list