Monticello API: raising exceptions

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

> 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 <[hidden email]> 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
>>
>

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

> On 22 January 2013 00:51, Chris Muller <[hidden email]> 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 <[hidden email]> 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
>>>
>>
>

> On Tue, Jan 22, 2013 at 7:30 AM, Frank Shearar <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>>>
>>>
>>
>