RE: ep

[Francisco Reverbel <reverbel at ime.usp.br>]

Andrei Goldchleger writes:

 > 1) Porque o writeTo retorna  um int ao inves de lancar uma excecao

Ele retorna o espaço que o objeto ocupou no buffer, ou zero caso o
objeto não tenha sido escrito porque ele ocuparia mais de maxLen bytes.
A exceção UTFDataFormatException só seria lançada numa situação muito
especial (vide abaixo), que na prática não deve ocorrer.

 > 2) Porque o writeto deve lancar uma utf...exception, mesmo q so tenha q
 > escrever ints, por exemplo.

Ele não *deve* lançar uma UTFDataFormatException. Ele *pode* lançar essa
exceção. É isto que a cláusula "throws UTFDataFormatException" diz.

Essa exceção só é lançada caso haja uma tentativa de escrita de um
String longa demais para ser convertida para o formato UTF, através do
método writeUTF(int pos, String s). O formato UTF tem um campo de
comprimento, com 16 bits de largura. Se esse comprimento não couber em
16 bits é lançada a exceção UTFDataFormatException.

A cláusula "throws UTFDataFormatException" foi incluída pensando no caso
em que o método writeTo() chama o método writeUTF(int pos, String s).

Note que há outro método writeUTF() (o que recebe o parâmetro maxCount)
que não lança essa exceção. 

> 3)Nao posso simplesmente usar o getsize para saber o tamanho do objeto e
> so chamar a writeTo se ele couber????

Sim, pode. Isso é um pouco menos eficiente, pois objetos tipo String
serão percorridos duas vezes: a primeira para descobrir o comprimento da
string em UTF, a segunda para escrever a string no buffer.

Mas note que se você usar a classe HFPage provavelmente você não
precisará se preucupar com chamadas a writeTo(). O método
HFPage.insertRecord() já cuida de chamar writeTo(). 

> 4) entre outras....

> Podemos ter a liberdade de alterar alguns itens da implementacao,
> mantendo a ideia geral?

Sim, desde sua implementação seja compatível com as interfaces e classes
especificadas na seção 2 ("A API do JBase") do enunciado.

Reverbel