-
Enhancement
-
Resolution: Won't Fix
-
P4
-
None
-
None
A DESCRIPTION OF THE PROBLEM :
If I want to throw an exception, that actually covers a causing exception, meaning I don't want the user to know or having to bother with the actual cause. Hence I don't want to attqach a cause to my exception. But that leads to the developer not knowing, where the exception is caused in my code.
Consider the following code:
##############
1: try {
2: // Some code
3: Statement s = ....; // Create a valid statement.
4: s.execute( "SELECT abcdef(1)" ); // Causing an SQLException!
5: // More code
6: } catch ( SQLException e ) {
7: throw new CustomExpception( "There was something wrong when fetching data from DB." );
8: }
##############
Receiving this CustomException in calling code and inspecting it's stacktrace the developer would only know, that the Exception was raised in line 7. When debugging it is worth a lot to know, that the cause of this exception is actually line 4, which you can only achieve by attaching the causing SQLException and inspecting the caused by stacktrace. But this leads to the developer being bothered with a lot of stack, that he will never be interested in. Well, of course there are cases, where a caused by is worth everything. But in many cases, where I want to cover the internals by a nice API and I don't want someone to look behind the sceness more than necessary.
I would suggest something like this:
7: throw new CustomException( "my message" ), e; // Inject e somehow, not passing it as a cause.
Here e is injected into the construction process (NOT as a cause!), and not through another constructor variant enabling me to use any existing exception. the super constructor would then extract the top line from the cause's stacktract and add it to the own one.
This way the stacktrace of the resulting CustomException would show line 4 as first line and line 7 as second line. The debugging person would know, where the exception has it's cause, where it is thrown and everything else without showing the actual cause (SQLException) the the outside world.
If I want to throw an exception, that actually covers a causing exception, meaning I don't want the user to know or having to bother with the actual cause. Hence I don't want to attqach a cause to my exception. But that leads to the developer not knowing, where the exception is caused in my code.
Consider the following code:
##############
1: try {
2: // Some code
3: Statement s = ....; // Create a valid statement.
4: s.execute( "SELECT abcdef(1)" ); // Causing an SQLException!
5: // More code
6: } catch ( SQLException e ) {
7: throw new CustomExpception( "There was something wrong when fetching data from DB." );
8: }
##############
Receiving this CustomException in calling code and inspecting it's stacktrace the developer would only know, that the Exception was raised in line 7. When debugging it is worth a lot to know, that the cause of this exception is actually line 4, which you can only achieve by attaching the causing SQLException and inspecting the caused by stacktrace. But this leads to the developer being bothered with a lot of stack, that he will never be interested in. Well, of course there are cases, where a caused by is worth everything. But in many cases, where I want to cover the internals by a nice API and I don't want someone to look behind the sceness more than necessary.
I would suggest something like this:
7: throw new CustomException( "my message" ), e; // Inject e somehow, not passing it as a cause.
Here e is injected into the construction process (NOT as a cause!), and not through another constructor variant enabling me to use any existing exception. the super constructor would then extract the top line from the cause's stacktract and add it to the own one.
This way the stacktrace of the resulting CustomException would show line 4 as first line and line 7 as second line. The debugging person would know, where the exception has it's cause, where it is thrown and everything else without showing the actual cause (SQLException) the the outside world.