Hope that help During the process of throwing an exception, the Java Virtual Machine abruptly completes, one by one, any expressions, statements, method and constructor invocations, initializers, and field initialization expressions that have begun but not completed execution in the current thread. This process continues until a handler is found that indicates that it handles that particular exception by naming the class of the exception or a superclass of the class of the exception (§11.2 <https://docs.oracle.com/javase/specs/jls/se11/html/jls-11.html#jls-11.2>). If no such handler is found, then the exception may be handled by one of a hierarchy of uncaught exception handlers (§11.3 <https://docs.oracle.com/javase/specs/jls/se11/html/jls-11.html#jls-11.3>) - thus every effort is made to avoid letting an exception go unhandled. https://docs.oracle.com/javase/specs/jls/se11/html/jls-11.html <https://docs.oracle.com/javase/specs/jls/se11/html/jls-11.html>
François > Le 30 mai 2020 à 16:52, smallufo <small...@gmail.com> a écrit : > > Francois Meillet <francois.meil...@gmail.com> 於 2020年5月30日 週六 下午10:48寫道： > >> sompage?67-1.-border-content-border_body-form is the path to your model >> > > Yes , but it may contains deep-nested model > > The form contains FormComponentPanel and contains another > FormComponentPanels and widgets , very deep ... > The error may lay under very deep model , which is very hard to debug. > And the error message should be able to pinpoint which model causes the > problem
