Programação OO, Sua opinião: Manipulação Logs devem gerar exceções?

XProtoman
(usa Fedora)

Enviado em 23/10/2015 - 19:35h

Boa noite,

Gostaria de saber a opinião de vocês, acho que deve ser a primeira ou uma das primeiras vezes que tento implementar uma Classe para gerar Logs, li um texto que foi publicado em setembro no br-linux que o autor dizia que um sistema de logs não deveria lançar exceções, discordando um pouco implementei com exceções porque em algumas operações elas podem ocorrer, seja manipulando o arquivo, seja na hora de pegar a data ou na hora de tratar a mensagem que será gravada.

O que você acha? Acha que uma operação de escrita no log deve ou não deve gerar exceções?

Thihup
(usa Manjaro Linux)

Enviado em 23/10/2015 - 20:50h

Olha, na minha opnião, caso eu fosse fazer um sistema de log, eu implementaria excessões com certeza!

Não sei o que os outros pensam, mas eu sim, eu implementaria.

Espero ter ajudado

[]'s

T+

--

body@human: $ sudo su
brain@human: # apt-get purge -y windows* && echo "Windows removed successfully"

jcoli
(usa Debian)

Enviado em 24/10/2015 - 07:10h

Com exceções com certeza.


Jeferson Coli
---------------------
www.tecnocoli.com.br

paulo1205
(usa Ubuntu)

Enviado em 25/10/2015 - 00:44h

Depende muito do caso.

Numa aplicação em que logar o que foi feito é apenas para de registro de informação, e a eventual perda da informação não constitui um problema vital para a aplicação, geralmente é melhor não gerar exceções. Imagine um servidor web, por exemplo, que loga as conexões num arquivo em disco, mas que não depende do disco para os dados que troca com os clientes, por manter dados relevantes num banco de dados ou utilizar apenas arquivos .PNG estáticos (em disco, mas read-only). Ele deve parar se acabar o espaço para os logs?

Em outros casos, por força de segurança ou até de lei (por exemplo, no caso de bancos ou empresas negociadas em bolsa, no que diz respeito a operações que possam influir nos balanços dessas empresas, e também no caso de provedores de conteúdo sujeitos a processos por calúnia ou difamação, que podem ter de revelar a identidade de seus usuários), o log é a informação mais importante, e se ele não puder ser gerado, a operação que motivou o log tem de ser impedida até que o seu devido registro possa ocorrer.

Pelo que você descreveu, você quer fazer algo parecido com uma biblioteca de logs, que pode ser usada em mais de um programa diferente. Nesse caso, talvez interesse ver casos de bibliotecas de log já implementadas em C e C++, avaliar seu funcionamento, e usar a experiência já existente em seu benefício.

O primeiro caso que me vem à mente é o do syslog do mundo UNIX. Sua API é em C e muito simples: uma função, openlog(), é opcionalmente chamada no início do programa, para (re)definir os parâmetros globais que serão usados durante toda a vida do programa, e outra, syslog(), é chamada a cada vez que se quer gerar uma informação de log em formato texto. Internamente, o que a função syslog() faz é reformatar ligeiramente o texto (acrescentando coisas, tais como data e hora e parâmetros definidos na possível chamada anterior a openlog()), e enviá-lo para um socket (que supostamente tem, na outra ponta, uma aplicação -- syslogd, rsyslod ou similar -- que vai receber a mensagem e gravá-la em disco ou reencaminhar para outro socket). A função syslog() tem tipo de retorno void, logo ela não oferece nenhum tipo de sinalização sobre se a mensagem foi registrada com sucesso. Isso reflete, na verdade, característica do próprio socket usado internamente para comunicação, que é do tipo SOCK_DGRAM, o que significa que ele mesmo não oferece mecanismos de sinalização (que é uma escolha totalmente justificável quando se pensa que se o programa esperasse a sinalização de um socket do tipo SOCK_STREAM, essa poderia demorar, e a operação de log poderia interferir com o desempenho da aplicação principal).

Outro caso de API para log, desta vez em C++, é o std::clog, declarado em <iostream>. Embora a princípio ele se pareça com std::cerr (porque ambos, por default, escrevem no mesmo descritor de arquivo que o stderr do C), existe uma distinção de propósito entre os dois: std::cerr é para apresentar mensagens que indicam anomalias de operação, ao passo que std::clog é para registrar qualquer situação, normal ou não. Como std::clog é uma instância da classe std::ostream, você pode contar com sinalizações de erro, e pode inclusive redefinir se quer que esses erros disparem exceções (que o seu programa pode tentar tratar ou não). Você também não está amarrado a usar o mesmo destino de std::cerr, pois você pode usar a função-membro rdbuf() para redefinir o destino aonde os dados serão enviados. Pode até criar (ou pegar pronta alguma que já exista) uma implementação de sockets com interface de streams (ou std::streambuf) é usá-la como backend de std::clog.

Esses exemplos foram só para dar uma ideia. Ambos trabalham só com texto puro e têm seus altos e baixos. Se você de fato está fazendo uma biblioteca para logs, pode tentar tirar o que cada uma tem de melhor, e também criar coisas próprias. Por exemplo, por que você não dá ao usuário da sua biblioteca a opção de definir se ele quer ou não exceções por meio de um parâmetro passado ao construtor da classe? Mas também não saia colocando recursos a torto e a direito: pense os casos em que a sua biblioteca poderá ser usada naqueles em que ela não deve ser usada, e proveja os recursos necessários ao seu público alvo.