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

[Erik Huelsmann]

Hi Ville,

On Fri, Jan 21, 2011 at 11:46 PM, Ville Voutilainen
<ville.voutilainen at gmail.com> wrote:
> 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.

Right. I think I should have said "discourage overriding". However,
the original getMessage() should be reduced to "return null" - I
think, because it's calling writeToString() which itself is calling
getMessage() again...

> 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).

Sure. It's just that I thought I'd help you get started :-)

Bye,

Erik.