[armedbear-devel] Design issue regarding condition printing (was: Error reporting problems)

[Ville Voutilainen]

On 21 January 2011 23:48, Erik Huelsmann <ehuels at gmail.com> wrote:
> With all these facts on the table, I think we need to do a few things
> to clean up the mess:
>  - Any condition overriding getMessage() in order to call FORMAT
> should be removed
>  - getConditionReport() should be documented not to be overridden, but
> to override getMessage() instead (maybe declare 'final'?)
> I'd greatly welcome any comments: it's a rather big change, judging by
> the description above. Ville, you were going to look at it, maybe you
> can verify if I'm half way right?

First of all, thanks for looking at the mess. Second, you really should leave
some bits of the work to the rest of us. :)

Anyway. Some comments, without having looked at the situation in detail:
1) disallowing overriding getMessage() feels wrong. The design may, and
likely is, incomplete, but I got a very vague feeling that the function
is serving a purpose. Now, I'm not entirely certain whether that purpose
exists on the lisp or the java side. I don't have a clear picture of that
yet.
2) if getConditionReport is not supposed to be overridden, then YES,
absolutely make it final. This actually is a point of endless philosophical
language debate. :) But, when we have a language at hand that
can do such static semantics checks, let's use the checks and forbid
overriding by using existing language facilities.

Off the top of my head, the checklist doesn't look incorrect - I just have
some doubts about it. I personally would like to do a bit of fiddling
with the codebase, and see if I get the same picture. That will at most
take an hour or two, and will probably result in my having a pretty
good idea about how to fix the problems.

So, let's give it a timeout of 1-2 days, if I can't produce anything
useful within that timeframe, feel free to hack it? :) (I'm exhausted
by work, no chance whatsoever to do fun stuff between Mon-Fri).