[squeak-dev] Monticello API: raising exceptions

Chris Muller asqueaker at gmail.com
Tue Jan 22 15:51:20 UTC 2013


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.

> 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
>>>
>>
>


More information about the Squeak-dev mailing list