API Projeto: Como deve classes distintas de erros ser tratado de uma chamada XMLHTTP assíncrona?

votos
0

Eu tenho um aplicativo VB6 legado que precisa para fazer chamadas assíncronas para um serviço web. O serviço web fornece um searchmétodo permite que os utilizadores finais para consultar uma base de dados central e visualizar os resultados a partir de dentro da aplicação. Eu estou usando o MSXML2.XMLHTTPpara fazer os pedidos, e tem escrito uma SearchWebServiceclasse que encapsula a chamada de serviço web e código para lidar com a resposta asychronously.

Atualmente, o SearchWebServicelevanta um dos dois eventos para o chamador: SearchCompletede SearchFailed. Um SearchCompletedevento é gerado que contém os resultados da pesquisa em um parâmetro para o evento, se a chamada for concluída com êxito. Um SearchFailedé gerado quando qualquer tipo de falha é detectada, o que pode ser qualquer coisa a partir de uma URL mal-formatado (isto é possível porque a URL é configurável pelo usuário), a erros de rede de baixo nível, como Host não encontrado, para HTTP erros, como erros de servidor interno. Ele retorna um string de mensagem de erro para o usuário final (que é extraído do corpo de resposta do serviço web, se presente, ou a partir do texto HTTP código de status se a resposta não tem corpo, ou traduzida a partir do código de erro de rede se um erro de rede ocorre).

Devido a vários requisitos de segurança, o aplicativo de chamada não acessar o serviço da web diretamente, mas em vez acessa-lo através de um servidor proxy da Web em execução no site do cliente, que por sua vez acessa o serviço web real através de através de uma VPN. No entanto, a SearchWebServicenão sabe que o aplicativo de chamada está a aceder ao serviço web através de um proxy: É apenas dado um URL e disse para fazer a solicitação. A existência do proxy é um requisito de nível de aplicativo.

O problema é que a partir de uma perspectiva do usuário final, é importante que o aplicativo de chamada ser capaz de distinguir entre erros de rede de baixo nível contra erros de HTTP a partir do serviço web, e para distinguir erros de proxy de erros de servidor web remoto. Por exemplo, o aplicativo precisa saber se um pedido falhou porque o servidor proxy é baixo, ou porque o serviço web remoto que o proxy está acessando é baixo. Uma mensagem específica do aplicativo precisa ser apresentado para o usuário final em cada caso, como Pesquisar servidor web proxy de serviço parece ser baixo. O servidor proxy pode precisar ser reiniciado versus O proxy está a funcionar, mas o controle remoto servidor web parece estar indisponível. por favor, entre em contato com (nome da pessoa encarregada do servidor web remoto). Eu poderia lidar com isso diretamente noSearchWebService classe, mas parece errado para gerar essas mensagens de erro de aplicação específica de uma classe tão genérica (e da classe pode ser usado em ambientes que não necessitam de um proxy, onde as mensagens de erro já não fazem sentido).

Esta distinção é importante para a solução de problemas: um problema no servidor proxy pode geralmente ser resolvido pelo cliente, mas um erro de servidor web remoto tem a manipulados por terceiros.

Eu estava pensando uma maneira de lidar com isso seria ter a SearchWebServiceclasse detectar diferentes tipos de erros e aumentar eventos diferentes em cada caso. Por exemplo, em vez de um único SearchFailedevento, eu poderia ter um NetworkErrorevento para erros de rede de baixo nível (o que indicaria um problema ao acessar o servidor proxy), um ConfigurationErrorevento para propriedades inválidas na SearchWebServiceclasse (como passar um URL mal-formatado) e um ServiceErrorpara os erros que ocorrem no servidor web remoto (o que implica que o proxy está a funcionar correctamente, mas o servidor remoto retornou um erro).

Agora que penso nisso, há também um cenário de erro adicional: ele poderia ser possível que o servidor proxy está funcionando corretamente, mas o servidor web remoto está baixo, ou o servidor proxy foi configurado incorretamente.

É a abordagem de usar vários eventos de erro para classificar diferentes classes de erro uma solução razoável para este problema? Para o último cenário (o proxy está funcionando, mas o servidor remoto não pode ser alcançado), eu estou supondo que eu possa ter de configurar o proxy para devolver um código de erro HTTP específica para que o cliente pode detectar esta situação (ou seja, algo mais específico do que uma resposta 500).

Originalmente eu mantive o único SearchFailedevento e simplesmente adicionado um adicional de errorCodeparâmetro para o evento, mas que se complicou rapidamente, especialmente nos casos em que não havia um código de erro lógico usar (como se o VB6 gera um erro real, ou seja, se a classe XMLHTTP não está registrado).

Publicado 27/08/2009 em 05:38
fonte usuário
Em outras línguas...                            


1 respostas

votos
1

Eu acho que algumas idéias que eu usei com exceções Java podem ser aplicadas aqui.

Ter um grande número de diferentes Exceções fica bastante complicado, mas precisamos dar detalhes suficientes para o usuário para que não querem perder informações.

Assim eu tenho um pequeno número de excepções específicas, que eu acho que corresponderia a seus eventos:

  • InvalidRequestEvent: Usado quando o usuário especifica informações ruim
  • TransientErrorEvent: usado quando há problemas de infra-estrutura, quando uma nova tentativa poderia funcionar.

I tendem a trabalhar em ambientes onde temos clusters de servidores por isso, se uma solicitação do usuário atinge um servidor moribundo, em seguida, se ele reenvia ele provavelmente vai receber uma boa, portanto, de sua perspectiva de uma repetição simples, muitas vezes funciona. No entanto, por vezes, o erro é com um serviço como a rede ou banco de dados e no caso em que o usuário precisa de informações de diagnóstico que informe o helpdesk. Assim, é preciso decidir sobre a informação extra para colocar no exceção. Este é (se eu entendi corretamente) a sua pergunta.

No caso de InvalidRequestException nós apostaria dando algumas informações sobre os problemas com a entrada. Pode estar nas linhas de "parenthese sem correspondência" ou "Desconhecido cutsomer coluna em ORDEM mesa". No caso de TransientErrorException poderia ser "servidor Proxy é baixo".

Agora, dependendo de seus requisitos exatos que você não pode realmente optar por colocar o texto na exceção, mas sim um número de erro que a camada de apresentação converte para uma cadeia específica de localidade (Inglês, Francês ...).

Então, de qualquer exceção pode conter algo como isto (pena de que a sintaxe Java, mas espero que a idéia é clara):

BaseException {
    String ErrorText;     // the error text itself

    // OR if you want to allow for internationaliation

    int ErrorCode;        // my application specific code, corresponds to text held by the UI
    String[] params;      // specific parameters to be substitued in the error text
                          // CUTSOMER and ORDER in my example above


    int SystemErrorCode;    // If you have an underlying error code it goes here


    String SystemErrorText; // any further diagnoistic you might need to give to 
                            // the user so that they can report the problem to the 
                            // help desk.

    // OR instead of the text (this is something I've seen done)

    int SystemErrorTag;     // A unique id for this particular error problem. 
                            // This server systems will label their message in the
                            // server logs. Users just tell the help desk this number
                            // they don't need to read detailed server error text.

}

Respondeu 27/08/2009 em 08:03
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more