Docsity
Docsity

Prepare-se para as provas
Prepare-se para as provas

Estude fácil! Tem muito documento disponível na Docsity


Ganhe pontos para baixar
Ganhe pontos para baixar

Ganhe pontos ajudando outros esrudantes ou compre um plano Premium


Guias e Dicas
Guias e Dicas


Tratamento de Exceções em C#: Série Qualidade no Código, Notas de estudo de Tecnologia Industrial

Saiba como tratar exceções em c# utilizando o mecanismo seh (structured exception handling). Este documento aborda a estrutura básica para tratamento de exceções, criando novas exceções personalizadas e boas práticas em código fonte. Além disso, aprenderá a evitar erros de hardware e intervenções de usuários.

Tipologia: Notas de estudo

Antes de 2010

Compartilhado em 01/10/2010

alisson-ferreira-11
alisson-ferreira-11 🇧🇷

5

(3)

7 documentos

1 / 13

Toggle sidebar

Esta página não é visível na pré-visualização

Não perca as partes importantes!

bg1
Série: QUALIDADE NO CÓDIGO 2007
[email protected]Página1
EXCEPTIONS – Você um dia terá uma!
Introdução:
Salve, salve DotNetianos!
Você já ouviu falar em Exception?
Exception representa uma condição excepcional, um comportamento
inesperado ou condição de erro, interrompendo o fluxo normal das
instruções durante a execução de um programa.
O .Net oferece um mecanismo robusto para tratamento de exceções.
Na realidade tratar exceções é o mesmo que tratar erros com classe,
elegância e sofisticação.
O .Net trata os erros como objetos que encapsulam informações
necessárias para resolvê-los. Esse mecanismo é conhecido como SEH
(Structured Exception Handling).
Esse poder provêm da biblioteca System.Exception.
Vejamos os membros do objeto Exception:
Propriedade Descritivo
HelpLink Retorna uma URL apontando para um documento HELP
com o descritivo do erro em detalhes
Message Descritivo do erro
Source Nome do objeto ou aplicação que gerou o erro
StackTrace Apresenta a seqüência de chamadas que dispararam
o erro
InnerException Apresenta exceções aninhadas
pf3
pf4
pf5
pf8
pf9
pfa
pfd

Pré-visualização parcial do texto

Baixe Tratamento de Exceções em C#: Série Qualidade no Código e outras Notas de estudo em PDF para Tecnologia Industrial, somente na Docsity!

EXCEPTIONS – Você um dia terá uma!

Introdução:

Salve, salve DotNetianos!

Você já ouviu falar em Exception?

Exception representa uma condição excepcional, um comportamento

inesperado ou condição de erro, interrompendo o fluxo normal das

instruções durante a execução de um programa.

O .Net oferece um mecanismo robusto para tratamento de exceções.

Na realidade tratar exceções é o mesmo que tratar erros com classe,

elegância e sofisticação.

O .Net trata os erros como objetos que encapsulam informações

necessárias para resolvê-los. Esse mecanismo é conhecido como SEH

(Structured Exception Handling).

Esse poder provêm da biblioteca System.Exception.

Vejamos os membros do objeto Exception:

Propriedade Descritivo

HelpLink Retorna uma URL apontando para um documento HELP

com o descritivo do erro em detalhes

Message Descritivo do erro

Source Nome do objeto ou aplicação que gerou o erro

StackTrace Apresenta a seqüência de chamadas que dispararam

o erro

InnerException Apresenta exceções aninhadas

Estrutura

Vejamos a estrutura básica para tratamento de exceções em C#

using System; namespace MSDNBrasil { class MainClass { public static void Main(string[] args) { try { // Código a ser executado } catch (TipoExceção1 e) { // tratamento da exceção } catch (TipoExceção2 e) { // tratamento da exceção } catch (Exception e) // erro genérico { // tratamento genérico } finally { // Este bloco de código sempre será executado, havendo ou não exceção! } } } }

Quando uma exceção for gerada, apenas um bloco catch é

executado, desviando o fluxo para o bloco finally (se este existir).

Digamos que uma exceção do tipo 1 é gerada, então apenas o bloco

catch (TipoExceção2 e) é executado, além do finally.

Gerando suas próprias exceções

Você também poderá gerar suas próprias exceções utilizando o

comando throw.

A figura 1 ilustra o primeiro exemplo sendo executado.

Exemplo 2 – Criando exceção explícita

No segundo exemplo criaremos uma exceção explícita.

using System; namespace MSDNBrasil { class MainClass { public static void Main(string[] args) { try { // Código int Hora = (System.DateTime.Now.Hour); if (Hora>13) { throw new Exception("Backup não poderá ser realizado após as 13 horas!"); } Console.WriteLine("Ok... Backup realizado"); // esta linha não será executada se horário > 13:59: } catch (System.Exception e) { // Apresenta o erro Console.WriteLine(e.Message); } finally { // Este bloco de código sempre será executado, havendo ou não exceção! Console.WriteLine("Simples, não é?"); } } } }

A figura 2 ilustra nosso segundo exemplo em execução.

Exemplo 3 – Criando novas exceções

No terceiro exemplo criaremos nossas próprias exceções.

using System;

namespace MSDNBrasil

class MainClass

public class eInvalidTime: Exception {}

public class eInvalidDay : Exception {}

public static void Main(string[] args)

try

// Código

int Hora = (System.DateTime.Now.Hour);

int Dia = (System.DateTime.Now.Day);

if (Dia ==8) {

throw new eInvalidDay();

if (Hora<22) {

throw new eInvalidTime();

Console.WriteLine("Ok... Backup realizado");

// esta linha não será executada se horário >

catch (eInvalidTime)

// Apresenta o erro para o tipo eInvalidTime

Console.WriteLine("------ erro: InvalidTime");

Console.WriteLine("O backup não poderá ser

realizado

antes das 22:00h ");

catch (eInvalidDay){

// Apresenta o erro para o tipo eInvalidDay

Console.WriteLine("------ erro: InvalidDate");

Console.WriteLine("Execute manualmente o

procedimento de backup");

finally

// Este bloco de código sempre será

executado,

havendo ou não exceção!

Console.WriteLine("Simples, não é?");

BOAS PRÁTICAS EM C#

Na maioria das discussões que participei acerca do assunto

“boas práticas ou qualidade em escrita de código fonte”,

percebi que se não interrompêssemos as manifestações mais

inflamadas o resultado continuaria muito distante de um

consenso. Em outras palavras, cada um tem uma posição muito

individual sobre a questão.

Realmente o assunto é polêmico na essência, pois o que é

qualidade para você?

Na intenção de apresentar minhas posições pessoais, escrevo nas

linhas seguintes alguns dos conceitos que a prática de 16 anos de

programação consolidaram em minha forma de escrever código

fonte.

Endentação

A primeira questão sobre o assunto endentação que podemos citar é

sobre o número de espaços entre os níveis. Por exemplo, o Visual

Studio.NET 2003 sugere como default 4 espaços conforme podemos

comprovar na imagem abaixo.

Na época que os monitores e as placas de vídeo não eram tão

poderosos, eu particularmente gostava de utilizar dois espaços para a

endentação. No final dos anos 90 eu já tinha aderido a 3 espaços e esta

é a minha opinião até hoje.

A próxima questão pode ser o tamanho máximo de uma linha de

código fonte. Neste quesito defendo que se deve evitar ao máximo

escrever linhas com mais de 80 posições entre espaços e caracteres. A

idéia é facilitar a compreensão do código e se possível visualizar a linha

inteira em seu editor de código.

Alguns trechos de código podem ficar muito extensos e você deverá

encarar o dilema de quebrar a linha. Eu naturalmente não gosto de

quebrar linhas de código, entretanto em situações necessárias aplico os

seguintes princípios:

  • Quebrar a linha após uma vírgula;
  • Quebrar a linha após um operador;
  • Alinhar a nova linha no inicio da expressão no mesmo nível da linha

anterior.

Fundamentalmente a questão é visual.

Para comentários de uma linha somente, tenho a seguinte opinião. Ou

o comentário deve uma espécie de marcador de loops ou não deve

ser aplicado. A questão é que como exposto em linhas anteriores, os

comentários devem chamar a atenção visando facilitar e direcionar a

manutenção. Somente justifica-se um comentário de uma linha quando

você necessita marcar dentro de um bloco de código o início de um

nível de endentação ou loop. Exemplo:

//Verifica se somente uma string foi entrada

if(args.Length==1)

Console.WriteLine(args[0]);

else

ArgumentOutOfRangeException ex;

ex = new ArgumentOutOfRangeException("Utilize somente uma

string");

throw(ex);

No exemplo acima utilizamos o comentário de uma linha com duas

barras “//” para explicar um bloco de código e marcar o seu nível de

endentação. Do trecho aonde este código exemplo foi retirado

existiam outras linhas de código antes e depois do bloco if / else.

Outra boa aplicação para comentários de uma linha é a explicação de

uma declaração. Por exemplo:

int levelStatus; // nível do status

int sizeStatus; // tamanho do status

Declarações

Sendo oportunista, declarar variáveis também deve apresentar uma

preocupação com a visibilidade. Por exemplo, eu não aconselho a

seguinte declaração:

int a, b;

Pode parecer exagero mas quando outro desenvolvedor for manusear

seu código fonte vai apreciar se encontrar a mesma declaração da

seguinte forma:

int a; // Valor de entrada 1

int b; // Valor de entrada 2

Para ser mais sincero e apresentar mais um conceito, tente sempre

inicializar suas variáveis no local aonde são declaradas. Sabemos que

nem sempre isto é possível, contudo bastante recomendável. Exemplo:

int a = 1; Valor de entrada 1

Permita-me um comentário adicional, não estou aconselhando nomear

uma variável inteira com "a", os exemplos anteriores visam explanar

outras questões

Nomes para componentes (notação húngara)

Sobre este tópico, após muitas demoradas discussões com meu amigo

Mauro Sant’Anna, concordamos sobre os seguintes pontos:

  • Não utilizar notação húngara. A notação é útil somente para

nomear componentes e, mesmo assim, quando existe a necessidade de

identificação facilitada do mesmo. Contudo se você não possui um

padrão para nomear componentes, de nada adiantará utilizar a

notação húngara.

  • Coloque nomes da forma mais clara possível, visando facilitar a

compreensão da finalidade da variável. Em nomes compostos, faça

combinações entre caracteres maiúsculos e minúsculos.

Exemplo:

string nomeUsuario;

int tempoIntervaloPadrao;

Finalizo esta matéria com a sensação que podia escrever muito mais,

contudo com a restrição de tamanho imposta pelas regras

estabelecidas. Agregando um valor adicional, a seguir uma sugestão

de nomes de componentes conforme a notação húngara.

Nomes para componentes (notação húngara)

VScrollBar vsb vsbMove Timer tmr tmrAlarm Splitter spt sptDivision DomainUpDown upd updPages NumericUpDown nud nudPieces TrackBar trb trbIndex ProgressBar prg prgLoadFile RichTextBox rtf rtfReport ImageList ils ilsAllIcons HelpProvider hlp hlpOptions ToolTip tip tipIcons ContextMenu cmn cmnOpen ToolBar tlb tlbActions StatusBar sta staDateTime NotifyIcon nti ntiOpen OpenFileDialog ofd ofdImage SaveFileDialog sfd sfdImage FontDialog ftd ftdText ColorDialog cld cldText PrintDialog ptd ptdText PrintPreviewDialog ppd ppdText PrintPreviewControl ppc ppcText ErrorProvider err errOpen PrintDocument prn prnText PageSetup Dialog psd psdReport CrystalReportViewer rpt rptSales

Data

Componente Prefixo Exemplo

DataSet dts dtsProducts

OleDbDataAdapter oda odaClients

OleDbConnection ocn ocnClients

OleDbCommand ocm ocmConsult

SqlDataAdapter sda sdaClients

SqlConnection scn scnClients

SqlCommand scm scmConsult

DataView dtv dtvConsult