On 22 January 2013 15:51, Chris Muller <asqueaker at gmail.com> wrote:
> On Tue, Jan 22, 2013 at 7:30 AM, Frank Shearar <frank.shearar at gmail.com> wrote:
>> OK, that actually got me a fair way. I still think we need an MCError,
>> but otherwise the change is to turn InstallerMonticello's mc into an
>> MCRepositoryGroup and make MCRepositoryGroup a bit more like an
>> MCRepository.
>
> If you want to resignal other errors as an MCError, if those
> exceptions cannot inherit from MCError (such as FileNotFoundException)
> then please at least wrap the original error in the MCError instance
> to facilitate easier debugging by knowing the real root-cause of the
> error.

Yes. I really, really like this pattern.

frank

>> As a neat side effect, I don't need a separate #failover: -
>> InstallerMonticello automatically checks the cace first (this is
>> default MCRepositoryGroup behaviour), and you add failovers just by
>> adding more repositories:
>>
>> Installer ss
>>     http: 'http://my.special.local.cache/';
>>     http: 'http://ss3.gemstone.com/ss/';
>>     project: 'Foo';
>>     install: 'Bar-fbs-22.mcz'
>>
>> will try install Bar-fbs-22.mcz first from the cache, then from ss,
>> then from a local cache, and finally from ss3.
>>
>> I need to roll out the change a bit further so all the other bits of
>> Installer work once more - #basicView:, #printOn: and so on - and then
>> should have something ready to be ripped apart by peer review.
>
> Great, thanks!
>
>
>> On 22 January 2013 00:51, Chris Muller <asqueaker at gmail.com> wrote:
>>> One design aspect of MC is that it supports many different "repository
>>> types".  So how about letting Installer install from a "composite"
>>> type -- in fact we already have MCRepositoryGroup which currently
>>> doesn't seem to have a lot of value -- so it could be an opportunity
>>> to make it more worth its weight without introducing any "new" API
>>> complexity.  The install script would just set up the
>>> MCRepositoryGroup instance with the repositories in the order they
>>> want and tell Installer to install normally using same existing API as
>>> the regular repository types (FileBased, etc.).
>>>
>>>
>>>
>>> On Mon, Jan 21, 2013 at 5:04 PM, Frank Shearar <frank.shearar at gmail.com> wrote:
>>>> I have a change to InstallerMonticello that allows it to fail over to
>>>> an alternate repository. That means that
>>>>
>>>> Installer ss
>>>>     package: 'Zippers';
>>>>     install: 'Zippers-fbs.52.mcz'.
>>>>
>>>> will attempt to load the mcz from the local cache, but fall over to
>>>> the canonical repository. Alternatively, one could say
>>>>
>>>> Installer ss
>>>>     package: 'Zippers';
>>>>     failover: (Installer ss3 package: 'Zippers'; mc);
>>>>     install: 'Zippers-fbs.52.mcz'.
>>>>
>>>> which would try SqueakSource before falling back to ss3.gemstone.com.
>>>> (I currently don't support multiple failovers, but I should.)
>>>>
>>>> Now to my question: if you try load a file from an
>>>> MCFileBasedRepository that does not exist, you get a
>>>> FileNotFoundException. I think this should be caught, and an MCError
>>>> (which doesn't exist yet, but should) raised. My rationale is this:
>>>> driving Monticello from the outside (like Installer does), I don't
>>>> care about the precise kinds of errors that may occur.
>>>> FileNotFoundException, NameLookupFailure, whatever, I only care that
>>>> MC failed to do something.
>>>>
>>>> In particular, I DO NOT want to catch Error. And, I DO NOT want to
>>>> scatter every possible kind of exception that might occur because a
>>>> user decided to use a GOODS repository and I forgot to figure out what
>>>> kinds of exceptions that kind of repository might throw.
>>>>
>>>> Thoughts? Rethrow underlying exceptions as a generic-but-specific-to-MC MCError?
>>>>
>>>> frank
>>>>
>>>
>>
>