Re: improving error messages?

[Jaroslav Hajek]

On Wed, Oct 21, 2009 at 1:20 PM, John W. Eaton <address@hidden> wrote:
> On 21-Oct-2009, Jaroslav Hajek wrote:
>
> | On Wed, Oct 21, 2009 at 12:48 PM, Søren Hauberg <address@hidden> wrote:
> | > ons, 21 10 2009 kl. 12:38 +0200, skrev Jaroslav Hajek:
> | >> I ended up with the attached patch. This seems to mostly solve my 
> problems:
> | >>
> | >> octave:1> cellslices (1:3, 1, 4)
> | >> error: cellslices: A(I): Index exceeds matrix dimension.
> | >> octave:1> any(1, 1.5)
> | >> error: any: conversion of 1.5 to int value failed
> | >> error: any: expecting dimension argument to be an integer
> | >>
> | >> I know this is no candidate for the best software design award, but it
> | >> works and is a relatively harmless change...
> | >>
> | >> Comments?
> | >
> | > Funny! I was thinking about the same problem just a few days ago, and I
> | > arrived at the same solution. One question, though:
> | >
> | > Let's say I'm developing a function 'A' that calls a bunch of other
> | > functions, i.e.
> | >
> | >  function A ()
> | >    ...
> | >    B ();
> | >    ...
> | >  endfunction
> | >
> | > what then happens if 'B' raises an error? Will I then get an error
> | > message from 'A' instead? This could potentially make it harder to
> | > develop functions or am I missing something?
> | >
> | > Søren
> | >
> |
> | No, you'll see a message from the innermost function that raised the
> | error, be it B or something else. And it only applies to errors
> | originating from liboctave exceptions (which generally have no way of
> | knowing who called them) or those generated by the C++ function
> | error_with_cfn (or error_with_id_cfn). So most user-generated errors
> | are unaffected.
>
> I think I'd rather not have to remember when it is appropriate to call
> error_with_cfn.

It's simple: if you want the auto-prepending. That is, almost never in
normal code. For liboctave exceptions, it's done automatically in the
handler; otherwise, you want to call it in places which want to throw
a generic error for multiple built-in functions, such as various
octave_value::XXX_value extractors.

> Maybe it would be better if we changed things so that
> the error function always reported the calling function information,
> and then changed our style to not include the function name as an
> error message prefix?
>

Better, maybe. The point is that code gets more easily changed than
style :) Besides, doing that would probably require massive changes
all over the place. The final thing is that we would have to make it
quite smart; often the user wants to ignore helper or internal
functions that actually invoke the error, without the need to catch,
subst the prefix and rethrow...

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz