> > + # Format warning messages.
> > + def format(message, category, filename, lineno):
>
> Should this function be indented so that it is located within
> self.__init__() or should it be referred to as self.function()? I'd
> prefer to stay away from functions nested within other functions.
> This nesting is very rare in relax and I'm slowly trying to eliminate
> all instances of it.
>
Fine.
I was just unsure as to what calls this function and whether it was
supposed to be nested.
> > + if issubclass(category, self.BaseWarning):
> > + message = "RelaxWarning: %s\n\n" % message
> > +
> > + if Debug:
> > + tb = ""
> > + for frame in inspect.stack()[4:]:
>
> It's probably worth trimming the other side of the stack as well, see below.
>
> > + file = frame[1]
> > + lineNo = frame[2]
> > + func = frame[3]
> > + tb_frame = ' File "%s", line %i, in %s\n' % (file,
lineNo, func)
> > + try:
> > + context = frame[4][frame[5]]
> > + except TypeError:
> > + pass
> > + else:
> > + tb_frame = '%s %s\n' % (tb_frame,
context.strip())
> > + tb = tb_frame + tb
> > + tb = "Traceback (most recent call last):\n%s" % tb
> > + message = tb + message
> > +
> > + return message
> > +
> > + warnings.formatwarning = format
>
> I had a very similar logic in the code which was rolled back at
> https://mail.gna.org/public/relax-commits/2006-08/msg00010.html
> (Message-id: <E1GDk40-0003vf-Do@xxxxxxxxxxxxxxxxxx>) and discussed at
> the thread starting at
> https://mail.gna.org/public/relax-devel/2006-08/msg00052.html
> (Message-id: <7f080ed10608100336r3dc92d80h1ce3251e55b49347@xxxxxxxxxxxxxx>).
> However I used the 'extract_stack' function to get the stack instead
> and then used the 'format_list' function to do the formatting similar
> to that which you have coded. The relevant code was in the traceback
> function which I've reproduced below. Some of the ideas in the code
> may be useful to further customise the traceback message.
Do you have anything specific in mind? Clearly your code is more
generally flexible, but is there anything you would like to apply that
flexibility to? If so feel free to modify/replace my suggestions.
It's not necessarily more flexible. The only idea that's interesting
is the trimming of both sides of the stack. For example when in
scripting mode then everything before, and including, the
interact_script() function and everything after the RelaxError or
RelaxWarning is of no use. However I don't currently have test case
data to see if there is anything after these points in the stack.
> > + # Base class for all warnings.
> > + ############################
> > +
> > + class BaseWarning(Warning, RelaxErrors.BaseError):
> > + def __str__(self):
> > + return self.text
>
> Does this need to be a subclass of RelaxErrors.BaseError?
I thought this was the best way to do it, but I'm happy to consider
other arguments. My logic was that if a warning is upgraded to an
exception, then it should be treated like any other relax error. This
means that when we need to catch all relax errors (eg. for UI specific
error handling) then we just need 'except BaseError' to do that. Are
there any reasons you are uncomfortable with this approach?
I didn't see that - I didn't realise that testing against the subclass
would catch it. Maybe if BaseError was renamed to RelaxBaseError it
will be automatically placed into __builtin__ (otherwise it could be
placed in there manually). This could then replace the
'AllRelaxErrors' data structure and all the tests for
'AllRelaxErrors'. That's a much more logical approach than mine.
Edward
Re: r2540 - in /branches/warning: errors.py generic_fns/pdb.py relax