You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Martin Grigorov (JIRA)" <ji...@apache.org> on 2011/03/27 12:20:05 UTC

[jira] [Commented] (WICKET-3548) Wrong exception type when readResolve fails.

    [ https://issues.apache.org/jira/browse/WICKET-3548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13011764#comment-13011764 ] 

Martin Grigorov commented on WICKET-3548:
-----------------------------------------

org.apache.wicket.util.lang.Objects.resolveClass(String) is used only by LazyInitProxyFactory in 1.4 and thus there are no breaks.
In 1.5 WicketObjects.resolveClass(String, Application) is used from many other places and throwing the exception breaks the build and many tests.
I reverted the change in 1.5 and implemented it another way.
@Igor: please review and either close the ticket, or add a comment or modify it. 

> Wrong exception type when readResolve fails.
> --------------------------------------------
>
>                 Key: WICKET-3548
>                 URL: https://issues.apache.org/jira/browse/WICKET-3548
>             Project: Wicket
>          Issue Type: Bug
>            Reporter: Maarten Billemont
>            Assignee: Igor Vaynberg
>             Fix For: 1.4.17, 1.5-RC3
>
>
> When readResolve in LazyInitProxyFactory fails because the type cannot be found, it dumps the real exception (ClassNotFoundException) and instead throws another one:
> 				throw new InvalidClassException(type, "could not resolve class [" + type +
> 					"] when deserializing proxy");
> The InvalidClassException is an invalid exception to throw in this case.  Ref. the JavaDoc for this exception:
>  * Thrown when the Serialization runtime detects one of the following
>  * problems with a Class.
>  * <UL>
>  * <LI> The serial version of the class does not match that of the class
>  *      descriptor read from the stream
>  * <LI> The class contains unknown datatypes
>  * <LI> The class does not have an accessible no-arg constructor
>  * </UL>
> The error is not caused by the type class being outdated, containing unknown datatypes or having no no-arg constructor.  The developer is mislead into thinking the problem is actually something else.
> Additionally, the real cause is masked and the real exception (found in "e"), is thrown away.  Instead, this method should throw a RuntimeException passing e as the cause.  Perhaps RuntimeException itself or an InvalidStateException.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira