sitelink1 | |
---|---|
sitelink2 | |
sitelink3 | |
sitelink4 | |
sitelink5 | |
sitelink6 |
1. http://jakarta.apache.org/commons/jelly/apidocs/org/apache/commons/jelly/util/NestedRuntimeException.html
=> A RuntimeException
which is nested to preserve stack traces. This class allows the following code to be written to convert a regular Exception into a RuntimeException
without losing the stack trace.
2. http://www.biojava.org/docs/api/org/biojava/utils/NestedRuntimeException.html
=> A general perpose RuntimeException that can wrap another exception.
In BioJava, checked exceptions are generally preferred to RuntimeExceptions, but RuntimeExceptions can be used as a fall-back if you are implementing an interface which doesn't support checked exceptions. If you do this, please document this clearly in the implementing class.
3. http://docs.jboss.org/jbossas/javadoc/3.2.7/common/org/jboss/util/NestedRuntimeException.html
=> A common superclass for RuntimeException classes that can contain a nested Throwable detail object.
4. http://opensource.objectsbydesign.com/spring-1.1.4/org/springframework/core/NestedRuntimeException.html
=> Handy class for wrapping runtime Exceptions with a root cause. This time-honoured technique is no longer necessary in Java 1.4, which provides built-in support for exception nesting. Thus exceptions in applications written to use Java 1.4 need not extend this class.
Abstract to force the programmer to extend the class. printStackTrace() etc. are forwarded to the wrapped Exception. The present assumption is that all application-specific exceptions that could be displayed to humans (users, administrators etc.) will implement the ErrorCoded interface. The similarity between this class and the NestedCheckedException class is unavoidable, as Java forces these two classes to have different superclasses (ah, the inflexibility of concrete inheritance!). As discussed in Expert One-On-One J2EE Design and Development, runtime exceptions are often a better alternative to checked exceptions. However, all exceptions should preserve their stack trace, if caused by a lower-level exception.
5. http://forum.java.sun.com/thread.jspa?threadID=602362&messageID=3264116
질문 :: How can I pass an exception from one thread to another thread
답변 ::
It really depends on what you want to do with your exception. Is there some sort of global handler that will process the exceptions in some meaningful way? Unless you have that, there's not much point in throwing an exception in a thread, unless you simply want the stack trace generated.
Presuming that you have a global handler that can catch exceptions, nest your Exception subclass inside a RuntimeException:
public class NestedRuntimeException extends RuntimeException{ private final m_nestedException; public NestedRuntimeException(final Exception originalException) { super("An exception occurred with message: " + originalException.getMessage()); m_nestedException; } public Exception getNestedException() { return m_nestedException; } }
댓글 0
번호 | 제목 | 글쓴이 | 날짜 | 조회 수 |
---|---|---|---|---|
3 | 파일 Download로직 구현시에 참고할만한 내용 | 황제낙엽 | 2006.12.27 | 483 |
2 |
파일을 web 이외의 경로에 올린다음 보내는 코드 예제 (JDK1.3)
![]() | 황제낙엽 | 2006.12.27 | 381 |
» | NestedRuntimeException | 황제낙엽 | 2006.09.22 | 1331 |