Re: [Prevayler-coders] Codehaus CVS converted to Subversion

[Jacob K. <ho...@vi...>]

Justin T. Sampson wrote:
> On Fri, Apr 4, 2008 at 11:46 AM, Jacob Kjome <ho...@vi...> wrote:
> 
>>  Hmm....  Creating our own SkaringaError for errors coming from the
>>  SkaringaSerializer seems overkill to me.  Personally, I'd limit custom
>>  exceptions to checked exceptions other than maybe general
>>  PrevaylerRuntimeException and PrevaylerError classes.
> 
> I'm sure I had good reasons for each of them. :) I'll review and
> document them as I roll them forward and see if we can come to some
> consensus.

May I ask where?  That is, in code existing in which repository?  First thing's 
first.  Let's get things ready for commits to happen.  It doesn't matter to me 
whether we use SVN or GIT, just that it gets out there.  In any case, the older 
repositories should be made available as a read-only repository and, minimally, 
archived and made available for download.

> 
> Part of the problem is that Java is pretty inconsistent about what
> exactly "errors", "runtime exceptions", and "checked exceptions"
> *mean*, so different projects come up with their own definitions. The
> only thing the language *enforces* is that checked exceptions are
> caught or declared, while runtime exceptions and errors aren't. (And
> Java 5 generics offer a loophole even to that enforcement.) Other
> kinds of semantics that are conceptually attached include the
> distinction between "abstraction-preserving" and
> "abstraction-violating" conditions (I'm not sure if I made up those
> terms myself or heard them somewhere) -- an OutOfMemoryError (which is
> an Error) is abstraction-violating, in the sense that it's not
> triggered by the abstract semantics of your code, but rather by the
> physical limitations of your machine; whereas a NullPointerException
> (which is a RuntimeException) is abstraction-preserving, because it
> *is* triggered by the abstract semantics of your code, and will happen
> regardless of the physical limitations of your machine.
> 

Those are excellent distinctions to make.

> So anyway, I was trying to stick to a particular set of
> interpretations / distinctions that would 1. make the usage of
> exceptions etc. consistent throughout the Prevayler code and 2. not
> conflict with any reasonable usage of exceptions in user code. In some
> cases those goals suggested using e.g. an Error instead of a
> RuntimeException, or introducing a distinct exception subclass, or
> even changing code that previously used an exception to use another
> mechanism entirely instead.
> 

I agree.  The only thing I disagree with is the need for distinct Exception and 
Error classes for each possible exception that might happen when 
PrevaylerException, PrevaylerRuntimeException, and PrevaylerError could suffice 
for most cases.

My example of the SkaringaException (which I mistakenly named "SkaringaError" 
above) is one of the most clear examples of this.  I mainly object to it because 
the primary subject of the failure is Prevayler, not Skaringa.  Skaringa is but 
one serialization implementation we use.  In this case, a PrevaylerIOException 
suffices, and may be unnecessary anyway since IOException is all the Serializer 
interface specifies anyway.  Because it is a checked exception, 
PrevaylerIOException is more acceptable to define as an extra Exception class in 
Prevayler, but unless it is defined in the interface and/or provides functionality 
above and beyond the base exception (such as accessors providing extra 
information, such as an object detailing the configuration of the system for 
debugging purposes), it is somewhat pointless to define a specific Exception/Error 
class.

If we are going to come up with new Prevayler-specific Exception/Error classes for 
every single possible problem, taken to its logical conclusion we will end up with 
  more of these classes than already exists in implementing the core functionality 
of Prevayler.  Besides that, if most of the cases are RuntimeException/Error, then 
it's the message and stack trace that important, not the name of the 
RuntimeException/Error.  A small set of generic, Prevayler-specific, 
Exception/Error classes that we use consistently throughout Prevayler will allow 
us to enforce the abstraction concepts you detailed above and, at the same time, 
keep from cluttering the codebase with an indefinite number of Exception/Error 
classes.

> (This experience and the generics experience have both fomented in me
> a strong preference for dynamically-typed languages...)
> 

I agree to a certain point.  But whenever I write client-side Javascript, I always 
find myself saying "boy, I wish I could define the exact type I expect in this 
function rather than having to type check it first thing inside the function."  A 
combination of type safety and dynamic features would be nice.


Jake

> Cheers,
> Justin