[Opensim-dev] Error detection when storing an asset

Jim Williams sphere1952 at gmail.com
Mon Apr 21 17:23:46 UTC 2014


" IMO lower level code should throw exceptions if something exceptional
happens and let the upper levels decide to retry or report the error."

If this was good programming practice then we wouldn't be having this
discussion.   I'd agree about it if exceptions would only
remain exceptional.  but programmer's are lazy bastards and will abuse
every feature offered to them whenever possible.

I'd argue that the code shouldn't know it is lower level, and ought to be
written defensively.  I watched overspecifed X.400 being blown away by
loosy-goosy SMTP precisely because every X.400 vendor thought they were
right and every SMTP installation had to deal with whatever came its way.
 Opensim is very fragile, and up-chucking exceptions is bound to be part of
the problem.




On Mon, Apr 21, 2014 at 11:13 AM, Mike Chase <
mike.chase at alternatemetaverse.com> wrote:

> That’s a shame but I understand.  I don’t understand the resistance to
> what I guess I consider good programming practice because there seems to be
> concern about “fixing” code that might be effected.  IMO lower level code
> should throw exceptions if something exceptional happens and let the upper
> levels decide to retry or report the error.
>
>
>
> Mike
>
>
>
> *From:* opensim-dev-bounces at opensimulator.org [mailto:
> opensim-dev-bounces at opensimulator.org] *On Behalf Of *Oren Hurvitz
> *Sent:* Monday, April 21, 2014 10:54 AM
> *To:* opensim-dev at opensimulator.org
> *Subject:* Re: [Opensim-dev] Error detection when storing an asset
>
>
>
> 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 <
> james.stallings at gmail.com> 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 <trinity93 at gmail.com> wrote:
>
> Im in mels camp on this one.
>
> Trinity Bays
>
>
>
> On Sat, Apr 19, 2014 at 4:14 AM, Melanie <melanie at t-data.com> 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 <orenh at kitely.com> 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
> Opensim-dev at opensimulator.org
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at opensimulator.org
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
>
>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at opensimulator.org
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
>
>
>
>
> --
>
> ===================================
>
> http://osgrid.org/
> http://simhost.com
> http://twitter.com/jstallings2
>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at opensimulator.org
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
>
>
>
> --
>
> Oren Hurvitz
> VP R&D
> Kitely Ltd.
>
> Email: orenh at kitely.com
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at opensimulator.org
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
>


-- 
No essence.  No permanence.  No perfection.  Only action.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20140421/f158d8a3/attachment.html>


More information about the Opensim-dev mailing list