You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hivemind.apache.org by "Hal Hildebrand (JIRA)" <hi...@jakarta.apache.org> on 2004/12/31 18:46:38 UTC
[jira] Created: (HIVEMIND-82) Exception handling needs to allow RuntimeExceptions through rather than wrapping them yet again
Exception handling needs to allow RuntimeExceptions through rather than wrapping them yet again
-----------------------------------------------------------------------------------------------
Key: HIVEMIND-82
URL: http://issues.apache.org/jira/browse/HIVEMIND-82
Project: HiveMind
Type: Improvement
Components: framework
Versions: 1.0, 1.1
Reporter: Hal Hildebrand
Priority: Minor
There's a lot of creation of ApplicationRuntimeExceptions, a RuntimeException, in the framework. There are also quite a number of error handlers for Exception which wrap the Exception in an ApplicationRuntimeException. All of these error handlers should have another handler for RuntimeException which allows these exceptions to blow through without wrapping.
for example, instead of:
try {
} catch (Exception e) {
throw new ApplicationRuntimeException(UtilMessages.invokeFailed(c, ex), null, ex);
}
this should be:
try {
} catch (RuntimeException e) {
throw e;
} catch (Exception e) {
throw new ApplicationRuntimeException(UtilMessages.invokeFailed(c, ex), null, ex);
}
This significantly cuts down on the redundant wrapping of ApplicationRuntimeExceptions. These redundant wrappings just make for HUGE stack traces which obscure where the problem really is. It also looks really ugly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
[jira] Commented: (HIVEMIND-82) Exception handling needs to allow RuntimeExceptions through rather than wrapping them yet again
Posted by "Johan Lindquist (JIRA)" <hi...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/HIVEMIND-82?page=comments#action_64525 ]
Johan Lindquist commented on HIVEMIND-82:
-----------------------------------------
Sounds good to me. I can pick that one up and supply a patch if you want, but considering the size, it might be easier to do it straight to cvs. Let me know.
> Exception handling needs to allow RuntimeExceptions through rather than wrapping them yet again
> -----------------------------------------------------------------------------------------------
>
> Key: HIVEMIND-82
> URL: http://issues.apache.org/jira/browse/HIVEMIND-82
> Project: HiveMind
> Type: Improvement
> Components: framework
> Versions: 1.0, 1.1
> Reporter: Hal Hildebrand
> Priority: Minor
>
> There's a lot of creation of ApplicationRuntimeExceptions, a RuntimeException, in the framework. There are also quite a number of error handlers for Exception which wrap the Exception in an ApplicationRuntimeException. All of these error handlers should have another handler for RuntimeException which allows these exceptions to blow through without wrapping.
> for example, instead of:
> try {
> } catch (Exception e) {
> throw new ApplicationRuntimeException(UtilMessages.invokeFailed(c, ex), null, ex);
> }
> this should be:
> try {
> } catch (RuntimeException e) {
> throw e;
> } catch (Exception e) {
> throw new ApplicationRuntimeException(UtilMessages.invokeFailed(c, ex), null, ex);
> }
> This significantly cuts down on the redundant wrapping of ApplicationRuntimeExceptions. These redundant wrappings just make for HUGE stack traces which obscure where the problem really is. It also looks really ugly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
[jira] Commented: (HIVEMIND-82) Exception handling needs to allow RuntimeExceptions through rather than wrapping them yet again
Posted by "James Carman (JIRA)" <hi...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/HIVEMIND-82?page=comments#action_64503 ]
James Carman commented on HIVEMIND-82:
--------------------------------------
I would say that the easiest way to go about this is to let the compiler tell us what's wrong...
1. Make all constructors private in ApplicationRuntimeException.
2. Create public static ApplicationRuntimeException wrap() methods corresponding to the signatures of the constructors. The wrap method would do exactly as you said, wrapping any exceptions that aren't already wrapped and simply returning those that are.
3. Fix all the code that uses the constructors directly, instead pointing them to the new wrap methods instead.
Does that make sense?
> Exception handling needs to allow RuntimeExceptions through rather than wrapping them yet again
> -----------------------------------------------------------------------------------------------
>
> Key: HIVEMIND-82
> URL: http://issues.apache.org/jira/browse/HIVEMIND-82
> Project: HiveMind
> Type: Improvement
> Components: framework
> Versions: 1.0, 1.1
> Reporter: Hal Hildebrand
> Priority: Minor
>
> There's a lot of creation of ApplicationRuntimeExceptions, a RuntimeException, in the framework. There are also quite a number of error handlers for Exception which wrap the Exception in an ApplicationRuntimeException. All of these error handlers should have another handler for RuntimeException which allows these exceptions to blow through without wrapping.
> for example, instead of:
> try {
> } catch (Exception e) {
> throw new ApplicationRuntimeException(UtilMessages.invokeFailed(c, ex), null, ex);
> }
> this should be:
> try {
> } catch (RuntimeException e) {
> throw e;
> } catch (Exception e) {
> throw new ApplicationRuntimeException(UtilMessages.invokeFailed(c, ex), null, ex);
> }
> This significantly cuts down on the redundant wrapping of ApplicationRuntimeExceptions. These redundant wrappings just make for HUGE stack traces which obscure where the problem really is. It also looks really ugly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
[jira] Commented: (HIVEMIND-82) Exception handling needs to allow RuntimeExceptions through rather than wrapping them yet again
Posted by "Howard M. Lewis Ship (JIRA)" <hi...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/HIVEMIND-82?page=comments#action_57219 ]
Howard M. Lewis Ship commented on HIVEMIND-82:
----------------------------------------------
Especially on JDK 1.4, it is very easy to write a top-level handler that digs down through the exception stack to find the deepest exception.
If you've used Tapestry, you know that each exception wrapper will, typically, add new information (either in the message, or the properties, or especially in the location property). This can be very useful for tracking down errors.
> Exception handling needs to allow RuntimeExceptions through rather than wrapping them yet again
> -----------------------------------------------------------------------------------------------
>
> Key: HIVEMIND-82
> URL: http://issues.apache.org/jira/browse/HIVEMIND-82
> Project: HiveMind
> Type: Improvement
> Components: framework
> Versions: 1.0, 1.1
> Reporter: Hal Hildebrand
> Priority: Minor
>
> There's a lot of creation of ApplicationRuntimeExceptions, a RuntimeException, in the framework. There are also quite a number of error handlers for Exception which wrap the Exception in an ApplicationRuntimeException. All of these error handlers should have another handler for RuntimeException which allows these exceptions to blow through without wrapping.
> for example, instead of:
> try {
> } catch (Exception e) {
> throw new ApplicationRuntimeException(UtilMessages.invokeFailed(c, ex), null, ex);
> }
> this should be:
> try {
> } catch (RuntimeException e) {
> throw e;
> } catch (Exception e) {
> throw new ApplicationRuntimeException(UtilMessages.invokeFailed(c, ex), null, ex);
> }
> This significantly cuts down on the redundant wrapping of ApplicationRuntimeExceptions. These redundant wrappings just make for HUGE stack traces which obscure where the problem really is. It also looks really ugly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
[jira] Commented: (HIVEMIND-82) Exception handling needs to allow RuntimeExceptions through rather than wrapping them yet again
Posted by "Johan Lindquist (JIRA)" <hi...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/HIVEMIND-82?page=comments#action_64499 ]
Johan Lindquist commented on HIVEMIND-82:
-----------------------------------------
I'd say re-throw the application runtime exceptions un-changed, wrapping any new, non-wrapped exceptions.
Maybe using a helper ...
public class SimpleExceptionHelper implements ExceptionHelper
{
public ApplicationRuntimeException composeApplicationRuntimeException(Throwable t)
{
if (t instanceof ApplicationRuntimeException)
{
return (ApplicationRuntimeException)t;
}
return new ApplicationRuntimeException(....);
}
}
Exception handling code would then be:
try {
} catch (Exception e) {
throw _exceptionHelper.composeApplicationRuntimeException(e);
}
What do you think?
> Exception handling needs to allow RuntimeExceptions through rather than wrapping them yet again
> -----------------------------------------------------------------------------------------------
>
> Key: HIVEMIND-82
> URL: http://issues.apache.org/jira/browse/HIVEMIND-82
> Project: HiveMind
> Type: Improvement
> Components: framework
> Versions: 1.0, 1.1
> Reporter: Hal Hildebrand
> Priority: Minor
>
> There's a lot of creation of ApplicationRuntimeExceptions, a RuntimeException, in the framework. There are also quite a number of error handlers for Exception which wrap the Exception in an ApplicationRuntimeException. All of these error handlers should have another handler for RuntimeException which allows these exceptions to blow through without wrapping.
> for example, instead of:
> try {
> } catch (Exception e) {
> throw new ApplicationRuntimeException(UtilMessages.invokeFailed(c, ex), null, ex);
> }
> this should be:
> try {
> } catch (RuntimeException e) {
> throw e;
> } catch (Exception e) {
> throw new ApplicationRuntimeException(UtilMessages.invokeFailed(c, ex), null, ex);
> }
> This significantly cuts down on the redundant wrapping of ApplicationRuntimeExceptions. These redundant wrappings just make for HUGE stack traces which obscure where the problem really is. It also looks really ugly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
[jira] Commented: (HIVEMIND-82) Exception handling needs to allow RuntimeExceptions through rather than wrapping them yet again
Posted by "James Carman (JIRA)" <hi...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/HIVEMIND-82?page=comments#action_12319027 ]
James Carman commented on HIVEMIND-82:
--------------------------------------
Does anyone have any objections to our proposed solution here?
> Exception handling needs to allow RuntimeExceptions through rather than wrapping them yet again
> -----------------------------------------------------------------------------------------------
>
> Key: HIVEMIND-82
> URL: http://issues.apache.org/jira/browse/HIVEMIND-82
> Project: HiveMind
> Type: Improvement
> Components: framework
> Versions: 1.0, 1.1
> Reporter: Hal Hildebrand
> Priority: Minor
>
> There's a lot of creation of ApplicationRuntimeExceptions, a RuntimeException, in the framework. There are also quite a number of error handlers for Exception which wrap the Exception in an ApplicationRuntimeException. All of these error handlers should have another handler for RuntimeException which allows these exceptions to blow through without wrapping.
> for example, instead of:
> try {
> } catch (Exception e) {
> throw new ApplicationRuntimeException(UtilMessages.invokeFailed(c, ex), null, ex);
> }
> this should be:
> try {
> } catch (RuntimeException e) {
> throw e;
> } catch (Exception e) {
> throw new ApplicationRuntimeException(UtilMessages.invokeFailed(c, ex), null, ex);
> }
> This significantly cuts down on the redundant wrapping of ApplicationRuntimeExceptions. These redundant wrappings just make for HUGE stack traces which obscure where the problem really is. It also looks really ugly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
[jira] Commented: (HIVEMIND-82) Exception handling needs to allow RuntimeExceptions through rather than wrapping them yet again
Posted by "James Carman (JIRA)" <hi...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/HIVEMIND-82?page=comments#action_64479 ]
James Carman commented on HIVEMIND-82:
--------------------------------------
What about this one, guys? What do we want to do with this?
> Exception handling needs to allow RuntimeExceptions through rather than wrapping them yet again
> -----------------------------------------------------------------------------------------------
>
> Key: HIVEMIND-82
> URL: http://issues.apache.org/jira/browse/HIVEMIND-82
> Project: HiveMind
> Type: Improvement
> Components: framework
> Versions: 1.0, 1.1
> Reporter: Hal Hildebrand
> Priority: Minor
>
> There's a lot of creation of ApplicationRuntimeExceptions, a RuntimeException, in the framework. There are also quite a number of error handlers for Exception which wrap the Exception in an ApplicationRuntimeException. All of these error handlers should have another handler for RuntimeException which allows these exceptions to blow through without wrapping.
> for example, instead of:
> try {
> } catch (Exception e) {
> throw new ApplicationRuntimeException(UtilMessages.invokeFailed(c, ex), null, ex);
> }
> this should be:
> try {
> } catch (RuntimeException e) {
> throw e;
> } catch (Exception e) {
> throw new ApplicationRuntimeException(UtilMessages.invokeFailed(c, ex), null, ex);
> }
> This significantly cuts down on the redundant wrapping of ApplicationRuntimeExceptions. These redundant wrappings just make for HUGE stack traces which obscure where the problem really is. It also looks really ugly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
[jira] Commented: (HIVEMIND-82) Exception handling needs to allow RuntimeExceptions through rather than wrapping them yet again
Posted by "Hal Hildebrand (JIRA)" <hi...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/HIVEMIND-82?page=comments#action_57220 ]
Hal Hildebrand commented on HIVEMIND-82:
----------------------------------------
True enough. It just seems that there are places where Exception is being caught without thinking about the ApplicationRuntimeException which would theoretically blow through the frame. In the case where I'm doing my own unraveling, one would have to know which exception wrapping was redundant and which wasn't.
Again, this isn't a big issue. It's just much more clear and concise (and simple) to not have the extra wrappings unless they are actually doing something.
> Exception handling needs to allow RuntimeExceptions through rather than wrapping them yet again
> -----------------------------------------------------------------------------------------------
>
> Key: HIVEMIND-82
> URL: http://issues.apache.org/jira/browse/HIVEMIND-82
> Project: HiveMind
> Type: Improvement
> Components: framework
> Versions: 1.0, 1.1
> Reporter: Hal Hildebrand
> Priority: Minor
>
> There's a lot of creation of ApplicationRuntimeExceptions, a RuntimeException, in the framework. There are also quite a number of error handlers for Exception which wrap the Exception in an ApplicationRuntimeException. All of these error handlers should have another handler for RuntimeException which allows these exceptions to blow through without wrapping.
> for example, instead of:
> try {
> } catch (Exception e) {
> throw new ApplicationRuntimeException(UtilMessages.invokeFailed(c, ex), null, ex);
> }
> this should be:
> try {
> } catch (RuntimeException e) {
> throw e;
> } catch (Exception e) {
> throw new ApplicationRuntimeException(UtilMessages.invokeFailed(c, ex), null, ex);
> }
> This significantly cuts down on the redundant wrapping of ApplicationRuntimeExceptions. These redundant wrappings just make for HUGE stack traces which obscure where the problem really is. It also looks really ugly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org