Bah, too bad I cant edit a sent email, as I mangled the last paragraph. The TL;DR:
Don't give up so damned easy Oren ;) On Mon, Apr 21, 2014 at 10:13 AM, James Stallings II < [email protected]> wrote: > Hi Oren, > > > FWIW, I agree with you completely wrt propagation of exceptions. I am > perhaps less concerned about whether this is ever reported to the user in > the viewer; that is a question for viewer developers to deliberate and > decide. To paraphrase Justin, whether a given piece of affected code > handles or ignores those exceptions is a different question entirely. For > me, it's about coding philosophy. > > > I am completely against any strategy that hides an error state. A properly > handled error state in the asset service might be the thing that first > alerts me to an impacted asset server, perhaps buying me sufficient time to > deal with it. In any event, I certainly don't want that call being made for > me by the programmer in a decision not to properly report an error > condition to the calling code. There are a shit-ton of other reasons why > this should never be done; but I'm not going to get crazy and start listing > them. Those who recognize the problem with doing things this way already > know, and the rest are wearing blinders and pedantically following legacy > practices. > > > My greater concern is that you will respond to the volume off these > objections rather than the number. There are two core dissenters, and they > are not superhuman (so neither correct nor otherwise in a state of grace by > default), so I would encourage you, if you really do think you have this > architectural issue solved, to pursue your case not for your own sake, but > for ours. > > > FYI I am not casting a vote as I am not core and so any vote I might cast > is not particularly relevant. > > Cheers > James/Hiro > > > On Mon, Apr 21, 2014 at 9:54 AM, Oren Hurvitz <[email protected]> wrote: > >> James, the only philosophical concern that I've heard is a desire to hide >> errors and present a false facade of 100% success to users. This was >> obfuscated by an attempt to claim that the errors could someday be fixed >> automatically, but that doesn't actually happen in today's OpenSim so it's >> not a valid point. Since I respect my users and value their time I have to >> let them know when I've failed to complete an action that they requested, >> so I reject this approach. >> >> A second possible objection is a practical one: will propagating >> exceptions cause other parts of the code, unrelated to the assets service, >> to fail? I don't know the answer to that, but I still refuse to pretend >> success in cases where I've failed. >> >> For these reasons, I have changed Kitely to propagate exceptions thrown >> in the communications system; it is already done. If this causes problems >> then I will see them and fix them. But in view of the surprising and >> vigorous opposition to this change I will not be contributing it to OpenSim. >> >> Oren >> >> >> >> On Mon, Apr 21, 2014 at 5:43 PM, James Stallings II < >> [email protected]> wrote: >> >>> Parhaps it would be interesting to hear whether Oren has obtained to >>> some elegant way of addressing these concerns. >>> >>> Cheers >>> >>> >>> On Sun, Apr 20, 2014 at 11:08 PM, Trinity <[email protected]> wrote: >>> >>>> Im in mels camp on this one. >>>> >>>> >>>> Trinity Bays >>>> >>>> >>>> On Sat, Apr 19, 2014 at 4:14 AM, Melanie <[email protected]> wrote: >>>> >>>>> These "other places" are what I'm worried about. There are a lot of >>>>> them and each of them would need to have code added. Exception handling >>>>> code is one of the worst types of code because the "try" is a scope, so >>>>> locals devlared in the try, like bool result = MethodToTry(); will have to >>>>> be split up into declaring the bool outside the scope and assigning it >>>>> inside - incredibly ugly for code that wants to be reference and teaching >>>>> code as well as a functioning system. >>>>> >>>>> - Melanie >>>>> >>>>> On 19 Apr 2014, at 08:02, Oren Hurvitz <[email protected]> wrote: >>>>> >>>>> My fix has two parts. >>>>> >>>>> The first is that the Store() operation needs to understand failures >>>>> correctly. There has been a consensus that it should, so I'll add that to >>>>> Git. >>>>> >>>>> The second is that MakeRequest() should propagate exceptions, instead >>>>> of just returning null (which is what it does now). So far there have been >>>>> 3 votes for this (me, Mike Chase, and Justin) and 2 against (Melanie, >>>>> Diva). That's very close; does anyone else want to make their position >>>>> known? >>>>> >>>>> Next, I see that there's confusion in this discussion about what >>>>> happens in Store() if MakeRequest() throws an exception. And the answer >>>>> is, >>>>> nothing will be different, because Store() already correctly catches >>>>> exceptions. That is precisely how it should work: the low-level >>>>> communications system reports when it has failed, and higher levels (that >>>>> know the business value of the call) decide how to handle it. However, >>>>> MakeRequest() is called from other places as well and they might need to >>>>> be >>>>> changed to handle exceptions better. >>>>> >>>>> _______________________________________________ >>>>> Opensim-dev mailing list >>>>> [email protected] >>>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>>>> _______________________________________________ >>>>> Opensim-dev mailing list >>>>> [email protected] >>>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> [email protected] >>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>>> >>>> >>> >>> >>> -- >>> =================================== >>> http://osgrid.org/ >>> http://simhost.com >>> http://twitter.com/jstallings2 >>> >>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> [email protected] >>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>> >>> >> >> >> -- >> Oren Hurvitz >> VP R&D >> Kitely Ltd. >> >> Email: [email protected] <[email protected]> >> >> _______________________________________________ >> Opensim-dev mailing list >> [email protected] >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >> >> > > > -- > =================================== > http://osgrid.org/ > http://simhost.com > http://twitter.com/jstallings2 > > -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2
_______________________________________________ Opensim-dev mailing list [email protected] http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
