<div dir="ltr">Bah, too bad I cant edit a sent email, as I mangled the last paragraph.<div><br></div><div>The TL;DR:</div><div><br></div><div>Don't give up so damned easy Oren ;)</div></div><div class="gmail_extra"><br>
<br><div class="gmail_quote">On Mon, Apr 21, 2014 at 10:13 AM, James Stallings II <span dir="ltr"><<a href="mailto:james.stallings@gmail.com" target="_blank">james.stallings@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Hi Oren,<div><br></div><div><br></div><div>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.<br>
<br><br>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.<br>
</div><div><br></div><div><br></div><div>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.</div>
<div><br></div><div><br></div><div>FYI I am not casting a vote as I am not core and so any vote I might cast is not particularly relevant.</div><div><br></div><div>Cheers</div><div>James/Hiro</div></div><div class="HOEnZb">
<div class="h5"><div class="gmail_extra">
<br><br><div class="gmail_quote">On Mon, Apr 21, 2014 at 9:54 AM, Oren Hurvitz <span dir="ltr"><<a href="mailto:orenh@kitely.com" target="_blank">orenh@kitely.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div>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.<br>
<br></div>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.<br>
<br>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.<span><font color="#888888"><br>
<br>Oren<br><br></font></span></div><div class="gmail_extra"><div><div><br><br><div class="gmail_quote">On Mon, Apr 21, 2014 at 5:43 PM, James Stallings II <span dir="ltr"><<a href="mailto:james.stallings@gmail.com" target="_blank">james.stallings@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Parhaps it would be interesting to hear whether Oren has obtained to some elegant way of addressing these concerns.<div>
<br></div><div>Cheers</div></div><div class="gmail_extra"><div><div><br><br><div class="gmail_quote">
On Sun, Apr 20, 2014 at 11:08 PM, Trinity <span dir="ltr"><<a href="mailto:trinity93@gmail.com" target="_blank">trinity93@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div>Im in mels camp on this one.<br><br><br></div>Trinity Bays<br></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Apr 19, 2014 at 4:14 AM, Melanie <span dir="ltr"><<a href="mailto:melanie@t-data.com" target="_blank">melanie@t-data.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<span><font color="#888888"><br>
- Melanie<br>
</font></span><div><div><br>
On 19 Apr 2014, at 08:02, Oren Hurvitz <<a href="mailto:orenh@kitely.com" target="_blank">orenh@kitely.com</a>> wrote:<br>
<br>
My fix has two parts.<br>
<br>
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.<br>
<br>
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?<br>
<br>
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.<br>
<br>
</div></div><div><div>_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@opensimulator.org" target="_blank">Opensim-dev@opensimulator.org</a><br>
<a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@opensimulator.org" target="_blank">Opensim-dev@opensimulator.org</a><br>
<a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@opensimulator.org" target="_blank">Opensim-dev@opensimulator.org</a><br>
<a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div></div></div><span><font color="#888888">-- <br><div dir="ltr">===================================<div><a href="http://osgrid.org/" target="_blank">http://osgrid.org/</a><br>
<a href="http://simhost.com" target="_blank">http://simhost.com</a><br>
<a href="http://twitter.com/jstallings2" target="_blank">http://twitter.com/jstallings2</a><br><br></div></div>
</font></span></div>
<br>_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@opensimulator.org" target="_blank">Opensim-dev@opensimulator.org</a><br>
<a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br></div></div><div><div dir="ltr">Oren Hurvitz<br>VP R&D<br>Kitely Ltd.<br><br>Email: <a href="mailto:orenh@kitely.com" target="_blank">orenh@kitely.com</a><a href="mailto:ilan@kitely.com" target="_blank"></a></div>
</div></div>
<br>_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@opensimulator.org" target="_blank">Opensim-dev@opensimulator.org</a><br>
<a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">===================================<div><a href="http://osgrid.org/" target="_blank">http://osgrid.org/</a><br><a href="http://simhost.com" target="_blank">http://simhost.com</a><br>
<a href="http://twitter.com/jstallings2" target="_blank">http://twitter.com/jstallings2</a><br><br></div></div>
</div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">===================================<div><a href="http://osgrid.org/" target="_blank">http://osgrid.org/</a><br><a href="http://simhost.com" target="_blank">http://simhost.com</a><br>
<a href="http://twitter.com/jstallings2" target="_blank">http://twitter.com/jstallings2</a><br><br></div></div>
</div>