ORIENTACAO A OBJETOS - CONCEITO

FFCOUTO 18/05/2013 17:52:33
#423709
Fox, entendi perfeitamente sua colocação e concordo plenamente.

Eu só tinha lido a sua primeira pergunta. Mas no fim tem outra falando sobre os msgbox nas camadas. Então sobre esta o que você disse está correto.

Todo erro que ocorre num camada de nível mais baixo deve ser repassada para o nível de cima até chegar no GUI. é isso.

Aproveite para implementar um log desses erros num banco de dados, é muito útil para correções posteriores.
KERPLUNK 20/05/2013 11:39:37
#423750
Pessoa, não esqueçam que o que vocês , são simplesmente classes que herdam de de Exception. Evitem tratar exeções pela mensagem. Ao invés disso, criem suas próprias exceptions:
C#

        [Serializable]
        public class DescricaoInvalidaException : Exception
        {
            public DescricaoInvalidaException() { }
            public DescricaoInvalidaException(string message) : base(message) { }
            public DescricaoInvalidaException(string message, Exception inner) : base(message, inner) { }
            protected DescricaoInvalidaException(
              System.Runtime.Serialization.SerializationInfo info,
              System.Runtime.Serialization.StreamingContext context)
                : base(info, context) { }
        }


VB.NET

<Serializable> _
Public Class DescricaoInvalidaException
	Inherits Exception
	Public Sub New()
	End Sub
	Public Sub New(message As String)
		MyBase.New(message)
	End Sub
	Public Sub New(message As String, inner As Exception)
		MyBase.New(message, inner)
	End Sub
	Protected Sub New(info As System.Runtime.Serialization.SerializationInfo, context As System.Runtime.Serialization.StreamingContext)
		MyBase.New(info, context)
	End Sub
End Class


Então, quando vocês fizerem, por exemplo, uma inserção de cliente e a descrição estiver incompatível por algum motivo, lancem essa exception:
C#

//Na GUI
try
{
    BLL.InsereCliente(meu_objeto_cliente);
}
catch (DescricaoInvalidaException ex)
{
    MessageBox.Show([Ô]A descrição do cliente está inválida: [Ô] + ex.Message);
}
catch (Exception ex)
{
    MessageBox.Show([Ô]algum outro erro ocorreu: [Ô] + ex.Message);
}

//Na BLL:
public void InsereCliente(objetoCliente)
{
    if (objetoCliente.Descricao.Legth > 60)
       throw new DescricaoInvalidaException([Ô]Descrição não pode ter mais de 60 caracteres[Ô]);
    try
    {
        DAO.InsereCliente(objetoCliente);
    }
    catch (Exception)
    {
       throw;
    }
}


Dessa maneira, lançando cada uma das possíveis exceções fica muito mais fácil de se validar seja o que for. Além disso, as classes de exceção que vocês lançam, podem conter propriedades que podem conter o objeto em que o erro ocorreu, excelente para Log, veja um exemplo:


        [Serializable]
        public class DescricaoInvalidaException : Exception
        {
            public DescricaoInvalidaException() { }
            public DescricaoInvalidaException(string message) : base(message) { }
            public DescricaoInvalidaException(string message, Exception inner) : base(message, inner) { }
            protected DescricaoInvalidaException(
              System.Runtime.Serialization.SerializationInfo info,
              System.Runtime.Serialization.StreamingContext context)
                : base(info, context) { }
            public Entidades.Cliente ClienteComErro {get; set;}
        }


Com isso, basta serialiar o conteúdo da proprieade [Ô]ClienteComErro[Ô], e você terá os dados que foram usados e pode gravar isso em um log se quiser, ou jogar na tela, ou enviar por e-mail... enfim, tratar como quiser.
KERPLUNK 05/07/2013 11:45:24
#425606
Esse tópico estava ficando bem interessante...
FFCOUTO 05/07/2013 16:20:56
#425627
Kerplunk, apesar do tempo parado, estou estudando tudo que foi passado aqui. Mas o tempo anda pouco neste último mês, devido alguns problemas aqui no meu serviço. Mas em breve vou postar algumas coisas que já andei modificando aqui.
F001E 10/07/2013 16:49:02
#425842
Eu to meio [Ô]burrão[Ô] no Exception...ainda não entrou na cabeça o jeito que o Kerplunk mencionou como fazer...
Posso fazer Exception no código todo ? Ou somente aonde poderá ocorrer algum erro ?...
Nesse código, uso Exception ou não ?...do jeito que esta o Exception é genérica...
KERPLUNK 12/07/2013 09:12:28
#425934
Citação:

Eu to meio [Ô]burrão[Ô] no Exception...ainda não entrou na cabeça o jeito que o Kerplunk mencionou como fazer...
Posso fazer Exception no código todo ? Ou somente aonde poderá ocorrer algum erro ?...
Nesse código, uso Exception ou não ?...do jeito que esta o Exception é genérica...



Você usa exceptions personalizadas aonde elas forem necessárias. Para você ter uma idéia, nesse mesmo form que você postou, crie uma excption assim:

        [Serializable]
        public class GridVazioException : Exception
        {
            public GridVazioException() { }
            public GridVazioException(string message) : base(message) { }
            public GridVazioException(string message, Exception inner) : base(message, inner) { }
            protected GridVazioException(
              System.Runtime.Serialization.SerializationInfo info,
              System.Runtime.Serialization.StreamingContext context)
                : base(info, context) { }
        }

é só pra exemplificar o uso de exceptions, mas veja no seu código você tem um [Ô]if[Ô] perguntando se o gridview1 contém linhas, vamos adicionar ali, uma condição [Ô]else[Ô] para dispararmos a exception:

if (gridView1.RowCount > 0)
....
else
    throw new GridVazioException([Ô]Gridview1 está vazio[Ô]);


Em seguida rode o código e faça com que o gridview1 fique vazio para cairmos na condição do else e depure o código.
Quando cair no [Ô]else[Ô], veja que a exceção será disparada e você vai ser direcionado para o [Ô]catch[Ô] do seu bloco try. Nesse caso, GridVazioException, será tratada como uma exceção genérica, mas é possível ver o tipo de exceção e a mensagem que colocamos ao disparar.
Então para melhor ainda exemplificar, adicione uma outra seção [Ô]catch[Ô]:

try
{
......
}
catch (Exception ex)
{
    Funcoes.Trataerro(.......
}
catch (GridVazioException)
{
    //aqui fazer o tratamento para um caso de grid vazio
}

Novamente rode o código depurando e faça com que gridview1 esteja vazio. Observe que a exception será disparada no bloco else e você será redirecionado para a seção catch, mas dessa vez, vai cair na exception para o grid vazio, a que adicionamos agora.

Entendendo esse conceito, você pode disparar e capturar exceções bem mais específicas e em muitas casos tratar ao invés de simplesmente mostrar o erro. No caso do exemplo, um grid vazio não tem o que ser feito para tratar, mas imagine, por exemplo que o usuário não preencheu um campo obrigatório. Nesse caso, você pode disparar uma exception [Ô]CampoObrigatorioVazioException[Ô] ou coisa assim, e no tratamento da mesma colocar um valor padrão e tentar novamente executar a rotina. As aplicações disso são muitas, basta usar a criatividade. O truque, é não enxergar todo e qualquer erro como fatal, onde simplesmente se mostra o erro e aborta a rotina, tem muita coisa que pode ser tratada, às vezes de forma automática, às vezes fazendo uma pergunta ao usuário, mas ainda assim, tratável.
F001E 12/07/2013 12:15:57
#425951
ahhh...agora eu entendi....o que eu estava fazendo era simplesmente mostrar o erro e com isso a aplicação não executava mais a partir desse erro...herança do VB6....heheh
F001E 12/07/2013 12:17:47
#425952
e eu posso criar quantas exceptions for necessária ? não existe limite para isso ?
EPISCOPAL 12/07/2013 13:22:05
#425956
é ..... muita tecnologia ..... que pena que se usar engenharia reversa do codigo da pra pegar o codigo fonte .... e nem me falem de embaraçador de codigo ... daqui uns 5 anos ... vai existir softwares que vai driblar os softwares criados hoje ...
KERPLUNK 12/07/2013 14:24:46
#425958
Citação:

:
e eu posso criar quantas exceptions for necessária ? não existe limite para isso ?


Não existe limite nenhum, você pode usar quantas exceptions quiser. Veja também que a exception em si, é uma classe e pode ter também métodos e propriedades, usando o mesmo exemplo:

        [Serializable]
        public class GridVazioException : Exception
        {
[txt-color=#e80000]            public string NomeDoForm { get; set; }[/txt-color]
            public GridVazioException() { }
            public GridVazioException(string message) : base(message) { }
            public GridVazioException(string message, Exception inner) : base(message, inner) { }
            protected GridVazioException(
              System.Runtime.Serialization.SerializationInfo info,
              System.Runtime.Serialization.StreamingContext context)
                : base(info, context) { }
        }

Assim, quando for disparar a excpetion, pode usar essa propriedade [Ô]NomeDoForm[Ô] e colocar por exemplo o nome do form, basta usar a imaginação, pode colocar até mesmo uma propriedade que por reflection serializa o objeto que causou a exception, ou qualquer outra coisa que quiser.


Citação:

:
é ..... muita tecnologia ..... que pena que se usar engenharia reversa do codigo da pra pegar o codigo fonte .... e nem me falem de embaraçador de codigo ... daqui uns 5 anos ... vai existir softwares que vai driblar os softwares criados hoje ...


1 - Usando engenharia reversa, você pega o código, mas se você não entende o conceito, código é pura bobagem
2 - Se você pegar simplesmente o código, pode fazer rodar, mas você não vai saber o que está acontecendo e se precisar de uma manutenção ou quiser mudar algo, vai ter que aprender os conceitos para poder lidar com o código
3 - Se você conhece os conceitos, o código é o de menos. O código nada mais é que conceito aplicado e se você conhece conceito, sabe fazer o código muito bem e por isso não vai precisar e nem querer fazer engenharia reversa.
Pense nisso, você está preso ao paradigma de código e não vai evoluir se não sair dele.
Página 3 de 14 [136 registro(s)]
Faça seu login para responder
Voltar