Issue 83978 - Basic runtime: unpack multiple WrappedTargetException errors, and error handling consolidation
Summary: Basic runtime: unpack multiple WrappedTargetException errors, and error handl...
Status: CLOSED FIXED
Alias: None
Product: App Dev
Classification: Unclassified
Component: scripting (show other issues)
Version: 3.3.0 or older (OOo)
Hardware: All All
: P3 Trivial
Target Milestone: ---
Assignee: joerg.skottke
QA Contact: Unknown
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-11-26 14:18 UTC by Frank Schönheit
Modified: 2013-02-24 21:00 UTC (History)
1 user (show)

See Also:
Issue Type: PATCH
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
patch (15.96 KB, patch)
2007-11-26 14:19 UTC, Frank Schönheit
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description Frank Schönheit 2007-11-26 14:18:41 UTC
Invoking, from within Basic, a method in a component of mine which throws a
WrappedTargetException, I found it somewhat unfortunate that the Basic IDE only
shows the message of the WrappedTargetException (which is of limited use to the
user, as it is often the case with "wrapping" exceptions), but not the message
of the exception which was actually wrapped.

Thus, I here propose a fix to the sbunoobj.cxx file, which actually unpacks a
"chain" of WrappedTargetExceptions. That is, if the
WrappedTargetException.TargetException member is a WrappedTargetException
itself, then it will also be handled, and so on.

For this, the patch modifies implHandleWrappedTargetException:
- first, if the exception is an InvocationTargetException, it is
  completely ignored. Note that this is what the old code does with
  completely ignoring any WrappedTargetException's message, silently
  assuming that it is always an InvocationTargetException.
- then, the message of the WrappedTargetException is appended to a string
  buffer.
- If the TargetException member of the error is also a WrappedTargetException,
  it continues with the previous step.
- If there is no WrappedTargetException anymore, but TargetException
  still contains an Exception object, this object's message is also
  appended.
- The special handling for BasicErrorException instances was preserved:
  "Traveling" the chain of WrappedTargetException's finishes if such
  a BasicErrorException is encountered.

Also, while I changed the code, I noticed there's a lot of duplicate code in the
exception handling, basically multiple
  catch ( FooException& e1 )
  {
    handleFooException( e1 );
  }
  catch( BarException& e2 )
  {
    handleBarException( e2 );
  }
  ...
blocks. Since there today exists a "::cppu::getCaughtException()", I took the
liberty to consolidate those blocks into single
  catch( const Exception& )
  {
    handleAnyException( ::cppu::getCaughtException() );
  }
blocks.

In the same course, the
  String implGetExceptionMsg( Exception& e )
was replaced with
  template< class EXCEPTION >
  String implGetExceptionMsg( const EXCEPTION& e )
, which means we now always display the type of the caught exception.
Comment 1 Frank Schönheit 2007-11-26 14:19:34 UTC
Created attachment 49908 [details]
patch
Comment 2 kai.sommerfeld 2007-11-27 08:03:37 UTC
fs: Andreas is currently on vacation. He will take care of the patch when he is
returned.
Comment 3 Mathias_Bauer 2007-11-27 21:09:18 UTC
wrong component
Comment 4 ab 2007-12-13 14:38:40 UTC
ab->fs: Sounds very good, Thanks :-)
STARTED, OOo 2.4, -> cws ab42
Comment 5 ab 2008-01-10 16:09:06 UTC
FIXED
Comment 6 ab 2008-01-11 14:06:42 UTC
ab->jsk: Please verify
It's difficult to verify this issue in detail as a big part is just code clean up.
But of course the exception error display should still work, e.g.:

Sub Main
	BasicLibraries.LoadLibrary( "ThisLibDoesNotExist" )
End Sub

should display:

BASIC runtime error
An exception occured
Type: com.sun.star.container.NoSuchElementException
Message: .
Comment 7 joerg.skottke 2008-01-16 11:59:33 UTC
Exceptionally verified.
Comment 8 joerg.skottke 2008-03-12 09:00:51 UTC
Closed