[geos-devel] GEOS Exceptions

[Mark Coletti]

On 4/18/05, Artem Pavlenko <artem at pavlenko.uklinux.net> wrote:

[...]

> Yes these changes will require clients to add small modifications and
> re-compile, but I reckon there are lots of potential users out there who
> don't consider GEOS precisely because of 'bugs' like this.

The exceptions thing isn't too egregious.  I don't think it's a deal
breaker with regards to deciding to use GEOS.  I'm guessing that many
users are unaware of the exception interface until one happens to get
thrown.  (Which looks like may have happened to Frank.  It's certainly
what happened to me.  And my efforts were more to get more useful
debugging information than improving GEOS design and implementation. 
Inheriting from std::exception provided a bit more debugging
information.)

> The Open source community deserves something better then MFC, doesn't it?

What does MFC have to do with GEOS?  

Actually, does anyone use MFC?   (On purpose?)

> These changes are trivial and must be applied now. This would give
> potential users confidence and speed up wider adoption of GEOS.

Again, though I urged making the aforementioned changes sooner than
later for pragmatic reasons, the exception interface isn't bad enough
to scare off people, especially given that most  probably won't notice
the exceptions until they're thrown.  (And then, sadly, most of them
might not know why throwing pointers to exception objects is a badism
and that there even exists an exception class hierarchy in the ISO
Standard C++ Library.)  GEOS happens to fill a much needed niche for a
C++ geospatial library; some might be so happy that one even exists
that they might not pay attention to the details.

Of course this is all just empty speculation.
 
> btw, I've done some work on WKT parser for my project (based on
> boost::spirit) and I'd like to share with GEOS if anyone is interested.
> I think it is a somewhat cleaner solution for the task.

I've looked at the Boost Spirit parser before and thought it was a
neat idea.  I thought it would be a great way to implement a WKT
parser.  You'd probably get some performance boost.  (No pun
intended!)  At the very least the code should (hopefully) be easier to
read, understand, and maintain.  Have you done any empirical
measurement to note any significant performance differences between
the old and new parsers?


Cheers,

MAC
-- 
I'm taking reality in small doses to build immunity.