[PATCH V4] subrepo: append subrepo path to subrepo error messages

[Matt Harbison]

Pierre-Yves David wrote:
> On 19 déc. 2012, at 01:37, Matt Harbison wrote:
>
>> On Tue, 18 Dec 2012 23:40:37 +0100, Angel Ezquerra wrote:
>>
>>> On Tue, Dec 18, 2012 at 11:35 PM, Angel Ezquerra
>>> <angel.ezquerra at gmail.com>  wrote:
>>>> # HG changeset patch
>>>> # User Angel Ezquerra<angel.ezquerra at gmail.com>
>>>> # Date 1355438273 -3600
>>>> # Node ID f15c5ad6479fd34258da8f78ff87c0ec6e90fd36
>>>> # Parent  34a1a639d8358e43f4bcba7b0cff19f4e4e6958d
>>>> subrepo: append subrepo path to subrepo error messages
>>>>
>> [..]
>>
>>> This new version tries to address the issues raised by Mads, Matt
>>> Harbison and Laurens. In particular I hope to have gotten the
>>> localization code right, changed the message from '(on subrepo XXX)' to
>>> '(in subrepo XXX)' for consistency's sake, avoid appending the message
>>> more than once and updated more of the subrepo tests (the ones I could
>>> run on windows work fine).
>>>
>>> Other than some tests that may fail on non windows platforms the only
>>> remaining issue (IMHO) is whether we should reduce the number of methods
>>> that are decorated to catch subrepo errors.
>>>
>>> It would be great if someone could run the tests on Linux. All other
>>> comments are also welcome!
>>>
>>> Cheers,
>>>
>>> Angel
>> The whole test suite runs cleanly on Linux.
>>
>> One question I didn't think of before, but does python support exception
>> chaining like Java does so you can get the whole trace, or will it be
>> truncated where the abort is caught and the abort subclass raised?  (Or is
>> that what the hint is?)  I think the feature is worthwhile even if it
>> can't be chained, but it might make debugging more of a pain.
>
> Yes \o/
>
> http://www.python.org/dev/peps/pep-0409/
>
> In python 3.3 /o\

That's too bad.  Would it be possible/acceptable (in another patch) to 
pass the original exception to the custom exception's constructor, and 
in dispatch._runcatch(), pass the original from the custom exception to 
ui.traceback()?  I realize that this is kinda nasty from a code 
organization POV, (why should dispatch know about something in the 
subrepo module?), but I think this is outweighed by being able to get 
the whole stacktrace with a simple --traceback when users report problems.

Are there any other similar issues with other parts of the code?  If so, 
maybe the custom exception should be a generic ChainedAbort class or 
something so this hack is reusable?

--Matt