[Mulgara-dev] [Mulgara-svn] r1264 - trunk/src/jar/resolver/java/org/mulgara/resolver

[Paul Gearon]

On Mon, Sep 22, 2008 at 11:47 PM, Life is hard, and then you die
<ronald at innovation.ch> wrote:
> On Mon, Sep 22, 2008 at 09:28:21PM -0700, pag at mulgara.org wrote:
>> Author: pag
>> Date: 2008-09-22 21:28:20 -0700 (Mon, 22 Sep 2008)
>> New Revision: 1264
>>
>> Modified:
>>    trunk/src/jar/resolver/java/org/mulgara/resolver/SetModelOperation.java
>> Log:
>> More flexible testing on source and destination graph URIs when inserting data
>>
>> Modified: trunk/src/jar/resolver/java/org/mulgara/resolver/SetModelOperation.java
> [snip]
>> +    } catch (Exception e) {
>> +      // source and destinations cannot be equal, so ignore
>> +    }
>
> I would strongly recommend never throwing an exception away without
> logging it, at least at level debug or trace. Too many times I've been
> debugging a problem, only to hit a wall because somebody decided to
> throw the exception stack trace away. To this end, on all projects I
> work on, we always have a rule where all exception stack traces must
> be logged eventually; this means that in a catch the exception must
> either be rethrown (no log necessary at this point), a new exception
> thrown with the caught exception as a cause (also no log necessary),
> or the exception must be logged. Logging at level debug is fine for
> expected exceptions.

Yes, I'd usually agree.... but not here.

I don't see the point in logging something that will happen on every
execution of a particular method (2 methods can call into this one,
and one of them will always generate this exception).

The exception shouldn't actually happen, but JRDF started using Sesame
code (unnecessarily, in this case) at some point, and it is the Sesame
code that doesn't like what can be passed in here. It's actually OK,
since all the code needs to do is check that the source and
destination are not the same, and if the source can't even be loaded
up as a URI, then it's definitely not the same as the destination
(which MUST be loadable).

Eventually I'll remove the Sesame dependence of the URIReferenceImpl
class, and this exception will go away. In the meantime, since it is
guaranteed to always occur, I'm not going to log it.

Paul