Prepara-te porque em breve terás muitas surpresas. É que o ABAP está a aprender troques novos. Repara neste: CONSTANTS: lc_menina TYPE STRING VALUE ‘MENINA', lc_menino TYPE STRING VALUE ‘MENINO’, lc_senhor TYPE STRING VALUE ’SENHOR’, lc_senhora TYPE STRING VALUE ‘SENHORA’. SELECT nome, CASE WHEN sexo_id = ‘M' AND idade < 18 THEN @lc_menino WHEN sexo_id = ‘F’ AND idade < 18 THEN @lc_menina WHEN sexo_id = ‘M' AND idade >=18 THEN @lc_senhor WHEN sexo_id = ‘F’ AND idade >=18 THEN @lc_senhora END AS titulo FROM zpessoa WHERE pessoa_id = @pessoa_id INTO CORRESPONDING FIELDS OF @lt_pessoas.

Relatórios que ainda escrevem directamente no ecrã são muito difíceis de manter quando é necessário alterá-los. Se o tiveres de fazer revê o código e, se o esforço não for demasiado, considera convertê-lo para ALV. Se tiveres dúvidas quanto às consequências disto, envolve um funcional nesta decisão.

Se ainda não usas classes de excepção fazes mal. Porque são muito boas para a saúde do código. Além de nutritivas, emagrecem-no e tornam-no mais resistente a doenças.

Mas há casos em que ainda é preciso lidar com as antigas excepções. Por exemplo quando se invoca um módulo de função.

Neste artigo apresento uma sugestão um bocado rebuscada mas que funciona muito bem para integrar as excepções antigas com classe de excepção de uma forma simples. A solução é rebuscada mas só tem de ser feita uma vez. Uma vez feita, a forma como se a usa não tem nada de rebuscado.

Historicamente os programas ABAP tendem a ser muito loooongos. Todas as boas prácticas de programação ensinam que não há uma única vantagem nisso. Se uma rotina, seja ela um programa, um método, uma função ou outra coisa, tiver mais do que 200-300 linhas, desconfia e considera seriamente modularizá-la em várias sub-rotinas. Esta abordagem tem a vantagem adicional de potenciar a reutilização de código. Mas a maior vantagem é o encapsulamento, isolando variáveis no seu contexto local, em vez de as ter todas juntas, tendo como resultado código mais seguro e mais claro.

Se o mesmo pedaço de código estiver repetido mais do que uma vez, pergunta-te porquê e tenta evitá-lo, criando uma rotina reutilizável. Se, num programa, existir mais do que um SELECT para a mesma tabela, tenta fundi-los num único. Por vezes a utilização inteligente de RANGES para unificar parâmetros pode evitar a necessidade de múltiplos SELECTs a uma mesma tabela. Se o mesmo código for usado em dois programas diferentes tenta, ao invés, mover esse código para uma classe que possa ser partilhada pelos dois.

Quanto mais variáveis globais existirem num programa, mais obscuro ele se tornará. Evita-as. Esta é uma das regras mais básicas da boa programação e deve ser seguida o mais possível. Mesmo se muitas variáveis tiverem de ser passadas entre rotinas. O esforço é um pouco maior, mas daí resultará código muito mais claro e seguro. Excepções podem ser feitas no caso de relatórios muito simples que revolvam à volta de uma única tabela interna, tabela esta que poderá ser declarada globalmente sem comprometer a clareza do código.

Há muito tempo atrás dizias “porreiro pá”. Depois começaste a dizer “baril”. Depois era “fixe”. Hoje dizes “altamente”. É importante não te baralhares para não dares mau aspecto.

E como perguntas a uma tabela interna se a linha existe?

Muitas vezes fazes READ TABLE itbl ou LOOP AT itbl apenas para verificar se um registo existe (CHECK SY-SUBRC = 0). Ora para isso, os dados do registo não são realmente necessários. Nestes casos usa sempre TRANSPORTING NO FIELDS. Assim evitas ter de declarar uma estrutura destino e o programa fica mais rápido porque não tem de perder tempo a copiar dados.

O Abapinho recebeu uma carta.

Sr Abapinho,

Todos sabemos como colocar valores por defeito em select options usando o comando DEFAULT. O que nem toda a gente sabe é que podemos também definir por defeito a opção e o sinal e mesmo o botão para restingir o select options.

Hoje vou ensinar-te a encadear excepções. É uma solução muito práctica para um problema complicado mas pouco óbvio.

Começo por descrever o problema.

Imagina que estás na aplicação BANANA. É uma aplicação bastante complexa. Tem, aliás, três módulos. São eles BANANA1, BANANA2 e BANANA3. Cada um tem a sua classe de excepção ZCX_BANANA1, ZCX_BANANA2 e ZCX_BANANA3. E como a aplicação até está bem desenhada, todas as classes de excepção herdam da mesma ZCX_BANANA. Agora imagina o seguinte cenário. Estás no módulo BANANA1 a fazer não sei o quê. E lá tens de chamar uma classe do módulo MORANGO Ora essa classe lança, claro, excepções, do tipo ZCX_MORANGO. Este é o contexto.

Tens várias hipóteses:

Quando chamas um módulo de função que devolve excepções normalmente dás-lhes números sequenciais tipo isto:

CALL FUNCTION 'VAI_ALI_MAS_VOLTA'
  EXPORTING
    ali = 'Barreiro'
  EXCEPTIONS
    NOT_FOUND = 1
    GOT_LOST  = 2
    OTHERS    = 3.

Mas se a seguir não tiveres o cuidado de ter um IF ou um CASE a olharem para o SY-SUBRC o Code Inspector pode devolve-te um erro caso esteja configurado para tal.

Temos duas variáveis:

DATA palavra1 TYPE string.
DATA palavra2 TYPE string.
DATA: frase TYPE string.

palavra1 = ‘isto’.
palavra2 = ‘aquilo’.

E queremos concatená-las metendo entre elas a palavra ‘mais’ e, claro, separando-as por espaços.

Não está.

Mas eles - os senhores que fazem e refazem o ABAP propriamente dito - vão tentando remediar a situação.

Olha por exemplo esta nova funcionalidade.

Sabias que podes fazer LOOP de uma tabela interna com uma estrutura A para dentro de uma estrutura do tipo B?

É comum encontrar o comando CHECK em user-exits. A trágica consequência disto é que, se o CHECK falha, nenhum do código que se segue a esse CHECK será alcançado. Como é comum (ainda que má prática) que num user-exit sejam tratados vários assuntos diferentes, um CHECK relacionado com um assunto pode inibir o acesso aos assuntos seguintes. Uma forma simples de evitar este risco é, como sempre aconselho, encapsular o código em rotinas.