Por que falar sobre manuseio de exceções no J2EE Project? Talvez muitos iniciantes em java queiram dizer: "Não é o manuseio de exceções, apenas tente ... Pegue ... finalmente? Todo mundo sabe disso!" O autor também pensa dessa maneira quando está aprendendo Java. Como definir a classe de exceção correspondente em um projeto J2EE de várias camadas? Como lidar com exceções em cada camada do projeto? Quando a exceção é lançada? Quando a exceção é registrada? Como registrar exceções? Quando devo converter a exceção verificada em exceção desmarcada e quando devo converter exceção desmarcada em exceção verificada? A exceção deve ser apresentada à página front-end? Como projetar uma estrutura de exceção? Essas questões serão discutidas neste artigo.
1. Manipulação de exceção de Java
Nas linguagens de programação processual, podemos determinar se o método é executado normalmente retornando o valor. Por exemplo, em um programa escrito no idioma C, se o método for executado corretamente, ele retornará 1. Se o erro for executado, ele retornará 0. Em um aplicativo desenvolvido por VB ou Delphi, quando ocorrer um erro, exibiremos uma caixa de mensagem para o usuário.
Não podemos obter os detalhes do erro através do valor de retorno do método. Pode ser porque o método é escrito por diferentes programadores, quando o mesmo tipo de erro ocorre em diferentes métodos, os resultados retornados e as informações de erro não são consistentes.
Portanto, o idioma Java adota um mecanismo de manuseio de exceção unificado.
O que é uma exceção? Erros capturáveis e processáveis ocorrendo em tempo de execução.
No idioma Java, a exceção é a classe pai de todas as exceções. Qualquer exceção é estendida à classe de exceção. A exceção é equivalente a um tipo de erro. Se você deseja definir um novo tipo de erro, estenda uma nova subclasse de exceção. A vantagem de usar exceções é que ele pode localizar com precisão o local do código -fonte que causa o erro do programa e obter informações detalhadas de erro.
O manuseio de exceção do Java é implementado através de cinco palavras -chave, tente, capturar, arremessar, arremessar, finalmente. A estrutura específica de manuseio de exceções é implementada pela tentativa… .Catch… .Finalmente bloqueando. O Try Block armazena declarações Java que podem ter exceções. A captura é usada para capturar a ocorrência de exceções e lidar com as exceções. O bloco final é usado para limpar os recursos não livres no programa. O bloco final é sempre executado se o código que não gerenciar como o bloco de tentativa retorna.
Um código de manuseio de exceção típico
public String getPassword (string userID) lança dataAccessException {String sql = "Selecione a senha do userInfo onde userID = '" +userID +"'"; string senha = null; conexão con = null; declaração s = null; resultSet rs = null; try {con -getConnection (); // get Data Conections s = Con. while (rs.Next ()) {senha = rs.getString (1);} rs.close (); s.close ();} catch (sqLexception ex) {tiro new DataAccessException (ex);} finalmente {try {if (con! falhou! ", sqlex);}} retornar senha;} Pode -se observar que as vantagens do mecanismo de manuseio de exceção de Java:
O erro é classificado uniformemente e implementado, estendendo a classe de exceção ou sua subclasse. Isso evita que o mesmo erro pode ter mensagens de erro diferentes em métodos diferentes. Quando o mesmo erro ocorre em métodos diferentes, você só precisa lançar o mesmo objeto de exceção.
Obtenha informações de erro mais detalhadas. Através de classes de exceção, informações de erro podem ser fornecidas à exceção mais detalhada e mais útil para o usuário. Fácil para os usuários rastrear e depurar programas.
Separe o resultado de retorno correto da mensagem de erro. Reduz a complexidade do programa. O chamador não precisa saber mais sobre o resultado de retorno.
Força o chamador a lidar com exceções para melhorar a qualidade do programa. Quando uma declaração de método precisa lançar uma exceção, o chamador deve usar a tentativa .... Catch Block para lidar com a exceção. Obviamente, o chamador também pode permitir que a exceção continue sendo jogada para o nível superior.
2. Exceção verificada ou exceção desmarcada?
As exceções de Java são divididas em duas categorias: exceção verificada e exceção desmarcada. Todas as exceções que herdam java.lang.Exception pertencem a exceções verificadas. Todas as exceções que herdam java.lang.runtimeException pertencem a exceções desmarcadas.
Quando um método chama um método que pode lançar uma exceção verificada, a exceção deve ser capturada e processada ou re-ampliada através do bloco de tentativa ... Catch.
Vamos dar uma olhada na declaração do método CreateStatement () da interface de conexão.
Declaração pública CreateStatement () lança SQLException; O SQLEXCECCION é uma exceção verificada. Quando o método de createstatements é chamado, Java força o chamador a capturar a SQLEXCECTION. public String getPassword (string userId) {try {... declaração s = con.createstatement (); ... catch (sqlexception sqlex) {...} ...} ou
public string getPassword (string userID) lança SqLexception {declaração s = con.createstatement ();} (É claro que recursos como conexão e satração precisam ser fechados a tempo. Isso é apenas para ilustrar que a exceção verificada deve forçar o chamador a pegar ou continuar a jogar)
A exceção desmarcada também é chamada de exceção de tempo de execução. Geralmente, a RuntimeTexception indica uma exceção que o usuário não pode recuperar, como a incapacidade de obter uma conexão de banco de dados, a incapacidade de abrir um arquivo etc. Embora o usuário também possa capturar exceções desmarcadas, como lidar com exceções verificadas. Mas se o chamador não pegar a exceção desmarcada, o compilador não o forçará a fazer isso.
Por exemplo, um código que converte caracteres em valores inteiros é o seguinte:
String str = "123"; int vale = integer.parseint (str);
A assinatura do método parseint é:
Public Staticint Parseint (strings) lança NumberFormatexception
Quando os parâmetros aprovados não podem ser convertidos no número inteiro correspondente, uma número do númeroForMexception será lançada. Como o númeroFormatexception se estende ao RuntimeException, é uma exceção desmarcada. Portanto, não há necessidade de tentar ... pegar ao chamar o método da parseint
Porque Java não força o chamador a pegar ou jogar a exceção sem controle. Portanto, os programadores sempre gostam de lançar exceções desmarcadas. Ou quando uma nova classe de exceção é necessária, ela é sempre usada para se estender da RunTimeException. Quando você chama esses métodos, se não houver bloco de captura correspondente, o compilador sempre permitirá que você passe e você não precisará entender que exceção esse método lançará. Parece que essa é uma boa ideia, mas isso está longe da verdadeira intenção do manuseio de exceções de Java. E é enganoso para o programador que chama sua classe, porque o chamador não tem idéia de que circunstâncias precisa lidar com exceções. A exceção verificada pode dizer claramente ao chamador o que as exceções precisam ser tratadas ao ligar para essa classe. Se o chamador não o processar, o compilador solicitará e não poderá compilar e passar. Obviamente, como lidar com isso depende do chamador decidir.
Portanto, a Java recomenda que as pessoas usem exceções verificadas em seu código de aplicativo. Assim como mencionamos na seção anterior que a vantagem de usar exceções é que ela pode forçar o chamador a lidar com as exceções que serão geradas. Exceções verificadas são usadas como padrão em documentos oficiais de Java, como "Java Tutorial".
Usar exceções verificadas deve significar que há muitas tentativas ... capturas no seu código. Depois de escrever e lidar cada vez mais ... Catch Blocks, muitas pessoas finalmente começaram a se perguntar se as exceções verificadas devem ser usadas como padrão.
Até Bruce Eckel, o autor do famoso "Thinking in Java", mudou seus pensamentos anteriores. Bruce Eckel até defende as exceções desmarcadas como uso padrão. E publique um artigo para testar se a exceção verificada deve ser removida do Java. Bruce Eckel: "Quando uma pequena quantidade de código, as exceções verificadas são, sem dúvida, um conceito muito elegante e ajudam a evitar muitos erros em potencial. Mas a experiência mostra que o resultado é exatamente o oposto para uma grande quantidade de código".
Para discussões detalhadas sobre exceções verificadas e exceções desmarcadas, consulte
Java Tutorial http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html
Usar exceções verificadas pode causar muitos problemas.
Exceção verificada causa muita tentativa ... Captura de código
Pode haver muitas exceções verificadas que não podem ser tratadas razoavelmente pelos desenvolvedores, como o SQLEXCECCECIONE. Mas os desenvolvedores precisam tentar ... pegar. Quando os desenvolvedores não conseguem lidar com uma exceção verificada corretamente, eles geralmente simplesmente imprimem a exceção ou não fazem nada. Especialmente para iniciantes, muitas exceções verificadas o fazem sentir perdido.
tente {… declaração s = con.createstatement ();… catch (sqlexception sqlex) {sqlex.printstacktrace ();} ou
tente {... declaração s = con.createstatement (); ... catch (sqlexception sqlex) {// não faz nada} Exceção verificada causa muitos codificadores difíceis de entender
Quando os desenvolvedores precisam pegar uma exceção verificada que não podem lidar corretamente, geralmente são reembalados em uma nova exceção e depois jogados. Fazer isso não traz nenhum benefício para o programa. Em vez disso, torna o código difícil de entender mais tarde.
Assim como usamos o código JDBC, há muita tentativa ... captura. O código realmente útil está incluído na tentativa ... captura. Dificultando a compreensão deste método
A exceção verificada faz com que a exceção seja constantemente encapsulada em outra exceção de classe e depois jogada
public void Methoda () lança excepção {… ..THOW NOVA excepciona ();} public void methodB () lança excepção {try {Methoda ();…} catch (excepciona ex) {throw new exceptionB (ex);}}} navroid methodc (), exceto ex {TryB (MethodB ();}}}}}; Vemos que a exceção é encapsulada e novamente camada por camada por camada.
Exceção verificada causa o método da interface corrupção
Um método em uma interface foi usado por várias classes. Quando uma exceção verificada adicional é adicionada a esse método, todos os códigos que chamam esse método precisam ser modificados.
Pode-se observar que os problemas acima são forçados a capturar e processar porque o chamador não consegue lidar com a exceção verificada corretamente e é forçada a encapsular e depois re-arremesso. Isso é muito inconveniente e não traz benefícios. Nesse caso, geralmente são usadas exceções desmarcadas.
A exceção verificada não é tudo. A exceção verificada é muito mais fácil de usar do que o valor de retorno de erro da programação tradicional. É muito melhor garantir que as exceções sejam tratadas corretamente através do compilador do que julgar pelo valor de retorno.
Se uma exceção for fatal, é irrecuperável. Ou o chamador vai pegá -lo sem nenhum benefício, use a exceção desmarcada.
Se uma exceção puder ser recuperada e puder ser tratada corretamente pelo chamador, use a exceção verificada.
Ao usar uma exceção desmarcada, a exceção desmarcada que o método pode lançar deve ser descrita em detalhes na declaração do método. O chamador decide se deve pegar a exceção sem controle
Quando usar exceções verificadas e quando usar exceções desmarcadas? Não existe padrão absoluto. Mas eu posso dar algumas sugestões
Quando todos os chamadores precisam lidar com essa exceção, o chamador pode poder tentar novamente a operação; ou a exceção é equivalente ao segundo valor de retorno do método. Use a exceção verificada.
Essa exceção só pode ser tratada por alguns chamadores mais avançados, e os chamadores comuns não podem lidar com isso corretamente. Use exceção desmarcada. Os chamadores que têm a capacidade de processar podem executar processamento avançado, mas geralmente os chamadores não lidam com isso.
Essa exceção é um erro muito grave, como erros de conexão do banco de dados, falha de arquivo em abrir etc. ou essas exceções estão relacionadas ao ambiente externo. Não é possível resolver o problema de tentar novamente. Use exceção desmarcada. Porque uma vez que essa exceção ocorre, o chamador não pode lidar com isso.
Se não tiver certeza, use uma exceção desmarcada. E descreva em detalhes a exceção que pode ser jogada para deixar o chamador decidir se deve lidar com isso.
3. Projete uma nova classe de exceção
Ao projetar uma nova aula de exceção, verifique se essa classe de exceção é realmente necessária. De um modo geral, tente não projetar novas aulas de exceção, mas tente usar classes de exceção que já existem no Java.
como
IllegalargumentException, UnsupportEdOperationException
Seja a nova exceção, uma exceção manchada ou uma exceção sem controle. Todos nós temos que considerar o problema de nidificação das exceções.
public void Methoda () lança excepção {… ..wlow New Exceptiona ();} Declaração do método MethodA lança exceção.
public void Methodb () lança excepçãoB
Declaração do MethodB lançará a ExceptionB. Quando o MethodA é chamado no método MethodB, a exceção não pode ser processada, portanto, a exceção deve continuar a expor. Uma maneira é fazer com que a declaração do MethodB seja excepcionária. Mas isso mudou a assinatura do método do MethodB. Uma vez alterado, todos os métodos que chamam MethodB devem ser alterados.
Outra maneira é encapsular a exceção na exceção e depois jogá -la. Se não encapsularmos a exceção na ExceptionB, perderemos as informações de exceção da raiz, tornando impossível rastrear a fonte original da exceção.
public void methodb () lança excepçãob {try {Methoda (); ...} catch (excepciona ex) {lança nova excepção (ex);}} Como no código acima, a ExceptionB faz uma exceção. Chamaremos a exceção de "exceção causou" por enquanto, porque a exceção faz com que a exceçãob ocorra. Isso impedirá que as informações de exceção sejam perdidas.
Portanto, quando definimos uma nova classe de exceção, devemos fornecer esse construtor que possa conter exceções aninhadas. E há um membro privado para salvar esta "exceção de causa".
classe pública ExceptionB estende a exceção {Causa de lançamento privado; Public ExceptionB (String msg, ex -jogável ex) {super (msg); this.Causa = ex;} public excepcionb (string msg) {super (msg);} public excepcionb (throwable ex) {this.cause = ex;}}}}} Obviamente, quando chamamos o método PrintStackTrace, precisamos imprimir todas as informações "causadas por exceção" ao mesmo tempo. Portanto, precisamos substituir o método PrintStackTrace para exibir todos os traços de pilha de exceção. Inclui traços de pilha de exceções aninhadas.
public void PrintStackTrace (PrintStrean PS) {if (Caus Um suporte completo para o código -fonte da classe de exceção verificada aninhada é a seguinte. Vamos chamá -lo de itensception aqui por enquanto
public nestedException estende a exceção {Causa de arremesso privado; public NordeException (String msg) {super (msg);} public nestedException (string msg, throwable ex) {super (msg); this.cuse = ex;} public throwsable getCause () {return (this.cuse == null? this: this; Super.getMessage (); Throwable Causa = getCause (); if (causa! = null) {message = message + "; exceção aninhada é" + causa;} retornar mensagem;} public void printStackTrace (printStream ps) {if (getCause == null) {super.printStackTrace (ps);} else {ps.println (this); getCausa (). printStackTrace (ps);}} public void printStackTrace (printWrite pw) {if (getCause () == null) {super.printStackTrace (pw);} else {pw.println (this); getCausa (). printStackTrace (pw);}} public void printStacktrace () {printStacktrace (System.error);}}Além disso, você precisa projetar uma classe de exceção desmarcada como acima. Só precisa herdar a RuntimeException.
4. Como registrar exceções
Como um grande sistema de aplicativos, os arquivos de log são necessários para registrar a operação do sistema para facilitar o rastreamento e a gravação da operação do sistema. Exceções que ocorrem no sistema naturalmente precisam ser registradas no sistema de log.
public String getPassword (string userID) lança NosuchuseRexception {userInfo user = userdao.quererSerbyId (userID); if (user == null) {Logger.info ("As informações do usuário não podem ser encontradas, userID ="+userID); throw nosuchUSEREX ("As informações do usuário não podem ser encontradas, UserID ="+UserID); Throw NosuchUSERX ("As informações do usuário não podem ser encontradas, UserID ="+UserID); user.getpassword ();}} public void sendUserPassword (string userID) lança a exceção {userInfo user = null; tente {user = getPassworth (userId); //… ..sendmail (); //} catch (noschuserexception ex) (logger.error ("essas informações do usuário não podem ser encontradas:" Percebemos que um erro foi registrado duas vezes. Na origem do erro, registramos apenas no nível de informação. No método SendUserPassword, também registramos todas as informações de exceção.
O autor viu muitos projetos registrar exceções dessa maneira, independentemente do 3721, e toda a exceção será registrada apenas ao encontrar uma exceção. Se uma exceção for continuamente encapsulada e jogada várias vezes, ela será registrada várias vezes. Então, onde a exceção deve ser registrada?
A exceção deve ser registrada no local inicial!
Se você precisar pegar uma exceção que não pode ser tratada corretamente, basta encapsulá -lo em outra exceção e colocá -lo. Não há necessidade de registrar a exceção registrada novamente.
Se uma exceção for capturada, essa exceção poderá ser tratada. Nenhuma exceção precisa ser registrada
public data getDate (string str) {date ApplyDate = null; simpledateFormat formato = new SimpleDateFormat ("mm/dd/yyyyy"); tente {ApplyDate = format.parse (aplicar -se, retornar);} catch (parseException ex) {// porquê, quando o formato está errado, retornar null} Quando uma exceção não registrada ou exceção externa do sistema é capturada, os detalhes da exceção devem ser registrados.
tente {… string sql = ”selecione * do userInfo”; declaração s = con.createstatement ();… catch (sqLexception sqlex) {Logger.error ("Erro de execução do SQL"+sql+sqlex);} Onde registrar informações de exceção e como registrar informações de exceção podem ser uma questão de opinião. Alguns sistemas até permitem que a classe de exceção registre exceções. Quando um novo objeto de exceção é gerado, as informações de exceção são registradas automaticamente.
public class BusinessException estende a exceção {private void logtrace () {StringBuffer buffer = new StringBuffer (); buffer.append ("Erro comercial na classe:"); buffer.append (getClassName ()); buffer.append (", método:"); "Buffer.ApmEnd (getMetHame (); buffer.fuffer. "); buffer.append (this.getMessage ()); Logger.error (buffer.toString ());} public BusinessException (strings) {super (s); race ();} Isso parece ser muito maravilhoso, mas inevitavelmente levará a exceção sendo registrada repetidamente. Ao mesmo tempo, viola o "princípio da distribuição de responsabilidades das classes" e é um design ruim. As exceções de gravação não pertencem ao comportamento da classe de exceção, e as exceções de gravação devem ser feitas por um sistema de log especial. E as informações anormais de gravação estão mudando constantemente. Estamos registrando exceções que devem fornecer informações mais ricas. Isso nos ajuda a encontrar a causa raiz do problema com base nas informações de exceção para resolver o problema.
Embora tenhamos discutido muito sobre a gravação de exceções, muita ênfase nessas torna os desenvolvedores mais confusos. Uma boa maneira é fornecer uma estrutura de manuseio de exceção para o sistema. A estrutura decide se deve registrar exceções e como registrar exceções. Não cabe aos programadores comuns decidir. Mas é benéfico saber de algo.
5. Manuseio de exceção no projeto J2EE
Atualmente, os projetos J2EE geralmente são divididos em várias camadas logicamente. Os clássicos são divididos em três camadas: camada de apresentação, camada de negócios e camada de integração (incluindo acesso ao banco de dados e acesso externo ao sistema).
O projeto J2EE tem sua complexidade, e várias questões precisam receber atenção especial ao lidar com exceções no projeto J2EE.
Ao usar aplicativos distribuídos, encontramos muitas exceções verificadas. Todas as chamadas RMI (incluindo chamadas de interface remota EJB) lançarão java.rmi.remoteexception; Ao mesmo tempo, a remoteexception é uma exceção verificada. Quando fazemos chamadas remotas no sistema de negócios, todos precisamos escrever uma grande quantidade de código para lidar com essas exceções verificadas. Uma vez que a remoteexception ocorre, essas exceções verificadas são muito graves para o sistema e quase não há possibilidade de tentar novamente. Em outras palavras, quando essas terríveis exceções verificadas, como a remoteexception, aparecem, não temos necessidade de tentar novamente, mas temos que escrever muita tentativa ... Capt Code para lidar com isso. Geralmente, fazemos chamadas RMI no nível inferior. Enquanto houver uma chamada RMI, todas as interfaces de nível superior exigirão que uma remoteexcepção seja lançada. Porque a maneira como lidamos com a remoteexception é continuar lançando -a. Isso destruirá nossa interface de negócios. Remoteexception Essas exceções no nível do sistema J2EE afetam seriamente nossas interfaces de negócios. O objetivo de nossa camada de sistemas é reduzir a dependência entre os sistemas, e as mudanças tecnológicas em cada camada não afetarão outras camadas.
// Public class Usersoaimplimples UsersOa {public userInfo getUserinfo (string userID) lança remoteexception {//… chamado de método remoto.// ……} Interface Public UserTeManager {public userinfo getUserinfo (string userID) remove remotexception;} Da mesma forma, o JDBC Access lançará uma exceção verificada da SQLEXCECTION.
Para evitar a profunda intrusão de exceções verificadas no nível do sistema no sistema de negócios, podemos definir a própria exceção de um sistema de negócios para o método de negócios. Para exceções muito sérias, como SQLEXCECTION e Remoteexception, podemos definir uma nova exceção desmarcada e, em seguida, encapsular o SQLEXCIPCECTION e Remoteexception em uma exceção desmarcada e jogá -la.
Se essa exceção no nível do sistema for entregue ao chamador anterior para manipular, você pode definir recentemente uma exceção comercial verificada e, em seguida, selar a exceção no nível do sistema em uma exceção no nível dos negócios e depois jogá-la.
Geralmente, precisamos definir uma exceção desmarcada, para que todos os métodos da interface da camada de integração declarem lançar essa exceção sem controle.
public DataAccessExceptionExtends RunTimeException {...} interface pública UserDAO {public String getPassword (string userID) lança dataAccessException;} public class UserDaoimplimples UserDAO {public String getPasswer (string userId) throwsAccessException {String sql = "Select de UserInfO (String UserId) WHERSTERACCESSCECCEIRA {String Sql =" Select de UserInfO (String) chama S.ExecuteQuery (SQL);…} Catch (SQLEXCECCIONE EX) {LONGE NOVA DATACESSEXCECTION ("Consulta de banco de dados falhou"+SQL, Ex);}}} Defina uma exceção comercial verificada, para que todos os métodos da interface da camada de negócios declarem lançar uma exceção verificada.
public class BusinessExceptionextends Exception{…..}public interface UserManager{public Userinfo copyUserInfo(Userinfo user)throws BusinessException{Userinfo newUser = null;try{newUser = (Userinfo)user.clone();}catch(CloneNotSupportedException ex){throw new BusinessException("The clone method is not Suportado: "+userinfo.class.getName (), ex);}}} A camada de representação J2EE deve ser uma camada muito fina e suas principais funções são: Obtenha solicitações de página, monte os parâmetros da página em objetos POJO, chame os métodos de negócios correspondentes e encaminhe a página, apresente os dados comerciais correspondentes à página. A camada de apresentação precisa prestar atenção a uma questão. A camada de apresentação precisa verificar a legitimidade dos dados, como alguns campos de entrada não podem estar vazios, verificação do comprimento do caractere, etc.
Todos os parâmetros passados de J2EE para o plano de fundo da página são do tipo de caractere. Se você precisar da entrada de parâmetros numéricos ou de tipo de data, o valor do caractere deverá ser convertido no valor numérico ou de data correspondente.
Se os parâmetros de verificação do código da camada de representação não forem válidos, ele deverá ser retornado à página original, permitindo que o usuário entre os dados e solicite informações relevantes para erros.
Geralmente, um parâmetro passado da página é convertido em um valor numérico, podemos ver esse código
Modeandview handlerequest (solicitação httpServletRequest, resposta httpServletResponse) lança a exceção {string agest = request.getParameter ("idade"); int ade = integer.parse (agest); ……… string birthdaystays = request.getParameter ("aniversário"); SimpleDateFormat formato = new SimpleDateFormat ("mm/dd/yyyy"); data aniversário = format.parse (birthdaystr);} O código acima deve ser visto com frequência, mas quando o usuário insere um caractere que não pode ser convertido em um número inteiro da página ou um valor de data incorreto.
O método integer.parse () é lançado uma exceção desmarcada com o númeroFormatexception. No entanto, essa exceção definitivamente não é uma exceção fatal. Geralmente, quando o valor inserido pelo usuário no campo de entrada da página é ilegal, devemos solicitar ao usuário a reentro. Mas uma vez que uma exceção desmarcada é lançada, não há chance de tentar novamente. Códigos como esse fazem com que uma grande quantidade de informações de exceção sejam exibidas na página. Faça nosso sistema parecer muito frágil.
Da mesma forma, o método SimpleDateFormat.Parse () também lançará uma exceção desmarcada da parseexception.
Nesse caso, devemos pegar essas exceções desmarcadas e levar o usuário a entrar novamente.
Modeandview handlerequest (solicitação httpServletRequest, httpServletResponse resposta) lança exceção {string agest = request.getParameter ("idade"); string birthdaystr = request.getParameter ("aniversário"); int idade = 0; ex) {error.reject ("idade", "não é um valor inteiro legal");} ……… tente {simpledateFormat format = new SimpleDateFormat ("mm/dd/yyyyy"); aniversário = format.parse (animações);} capt (no nada é o date); 'Mm/dd/aa' formato ');}} Na camada de apresentação, você deve descobrir se o método de chamada lançará uma exceção desmarcada, em que circunstâncias essas exceções serão lançadas e farão o processamento correto.
Na camada de apresentação, não há necessidade de capturar exceções em geral. Se a exceção lançada pelo método de negócios chamado for equivalente ao segundo valor de retorno, neste caso, é necessário capturar.
O exposto acima é todo o conteúdo deste artigo. Espero que seja útil para o aprendizado de todos e espero que todos apoiem mais o wulin.com.