[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-GIFT] Inconsistency in MRML? - perhaps there should be an MRML
Re: [bug-GIFT] Inconsistency in MRML? - perhaps there should be an MRML warning message?
Thu, 27 Sep 2001 23:05:27 +0200
I guess you don't mind that I put the answer of your message to the list, as
I think it's important, and I assume you just forgot to do a reply-all
instead of a reply.
On Thursday 27 September 2001 22:16, David Squire wrote:
> > In fact the exception business was cancelled, when I realized
> > that the gcc
> > 2.81 did EITHER support exceptions, OR runtime type
> > identification (RTTI),
> Perhaps I have misunderstood, but I certainly tracked down where in the
> code the error message was being generated, and it seemed like an exception
> to me.
Nono, you're not getting anything wrong. There ARE exceptions in the code,
mainly to find out when it WOULD work. Exceptions and RTTI work nicely (at
least for me, and only as far as I know) since g++ 2.95 . However, these
exceptions are not treated in the thorough fashion they deserve (this is what
I mean with "having quit the exception business"), and especially
they get caught in the same file in which they are thrown instead of the
right place (at least in one case, and I remember having left things in this
> Question: is there any good reason why an algorithm which is requested in a
> query should not automatically be configured if it has not already been?
You will laugh, but two years ago I started out this way, and then I quit
because of said exception trouble. But yes, I think that it is good to
request at least a bit of rigor from the client. I find it's better to give
the client some message
"Hya, you did not configure correctly"
than giving some results, where the user never finds out if it was what he
> > What I will write "soon" is orderly exception handling which should also
> > avoid the annoying crashes we get in certain situations. When
> > this exception
> > business is done, calling for an unconfigured algorithm will give you an
> > error (mrml error message, which the client can show).
> Regarding the "collection", "collection-id" thing, perhaps the server
> should return some sort of mrml warning message when it receives elements
> it does not recognize. This would not violate the graceful degradation
> principle, since the client could ignore them, but it would help developers
> to find out what is going on.
I do think it violates something: Imagine somebody sending region queries
with plenty of tags, causing lots of error messages on top of the normal
stuff... I would regard it as useful to be able to send something like a
attribute with the top-level mrml tag. Than you can program a reaction to the
tag like <!-- unknown tag <sumpn> contents of this tag ignored -->
To summarise the reactions I will take to our series of mails is that I am
looking into the exception business NOW for some parts of the evening, and I
will see in a more detailed fashion how things can be moved in the right
direction. The goal of this is to make the gift more stable. As I see things,
instability is mainly in libMRML, so changes there will benefit all query
After that we can see, how we can include such a debug-level tag into the
gift. We would also have to create something flexible for how to let the gift
know what's unknown... See what I mean? All parts have to know what they
know. I guess that there will be some cui-known-tag-list in the
configuration, and a special visitor which generates warnings?
Dr. Wolfgang Müller, assistant == teaching assistant
Personal page: http://cui.unige.ch/~vision/members/WolfgangMueller.html
Maintainer, GNU Image Finding Tool (http://www.gnu.org/software/gift)
- Re: [bug-GIFT] Inconsistency in MRML? - perhaps there should be an MRML warning message?,
Wolfgang Mueller <=