Re: [zzdev] Re: [zzdev] Errors and exceptions

["B. Fallenstein" <b.fallenstein@xxxxxx>]

Tuomas Lukka wrote:
> > > > I agree with the classes you mention, but we also need a SyntaxError or
> > > > similar kind of thing for malformed structures: the program expects some
> > > > ZZ structure, but gets something else. This should probably be an error,
> > > > because it usually needs to be handled by the user somehow, not the
> > > > calling function.
>
> Alternatively, a class ClangException, from which e.g. SyntaxError is
> derived. Then, all methods which execute language have 'throws ClangException'
> as a throws clause.

Absolutely agreed. (Do we really need to prefix that it with 'ZZ'?
'ClangException' seems to be unique enough. 'InfiniteLoopException'
should IMO not be prefixed either, because the loop detector is not
connected to ZZ except that the code was written on this project.)

I was mixing non-clang related stuff in, though (separating that does
make sense): strange ZOb/bindings/window cell/etc. system structures
which are not the way the system expects them to be. I think there
should be an error encompassing that kind of thing (we might want to
give a special kind of feedback to the user). Anyway, that would be more
clear than a NullPointerException (only if you take the time to write a
meaningful error message instead of letting the NullPointerException
bubble up, of course, but you should do that). So I think we should have
an exception for that, too.

> > I don't think renderables should be there at all. The current interface
> > for decorations is holding us back. I'm not sure yet how we can improve
> > on it, but fixing it at this point seems to be totally unreasonable.
> 
> Hmm... Renderable is not meant to solve this: Renderable is something
> that is simply painted at some depth.

I know; that's why I think we shouldn't keep it. I'm not clearly opposed
to it, don't get me wrong, I just do not see what we need it for. We can
always use a vob without a cell the way we use Renderables now, and we
do not need additional efficiency if we don't do the connections that
way anyway. Or am I missing something? What is the use for renderables
you foresee?

> Probably something like "Connection" or "VisualConnection".

Considering the current naming, "Connection2D"?

> Yes, maybe connections really do need to be completely outside the
> current flat-2 1/2 D vob system. That would make sense.
> 
> Hmm, we probably should support this in the core APIs - suggestions?

Why, the core APIs should be more or less frozen; so we should IMO not
add something there we have *no* experience with so far. It doesn't cost
us much to move stuff there later. ;o) What about this: I write a first
experimental implementation sometime next week (hope I'll be able to do
that), and then we see how it works and what we'd like to change before
moving it to core.


Something else: Why do the core/ vobs not have anything related to
interpolation in them?
-b.