Mailing-List: contact axis-c-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache AXIS C Developers List" <axis-c-dev@ws.apache.org>
Message-ID: <818758526.1120562530294.JavaMail.jira@ajax.apache.org>
Date: Tue, 5 Jul 2005 13:22:10 +0200 (CEST)
From: "Dushshantha Chandradasa (JIRA)" <axis-c-dev@ws.apache.org>
To: axis-c-dev@ws.apache.org
Subject: [jira] Updated: (AXISCPP-722) Overloaded processException in
 AxisEngineException class
In-Reply-To: <32668418.1120190757050.JavaMail.jira@ajax.apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

     [ http://issues.apache.org/jira/browse/AXISCPP-722?page=3Dall ]

Dushshantha Chandradasa updated AXISCPP-722:
--------------------------------------------

    Attachment: ExceptionModel_before.JPG

Samisa wrote:

PFA the class diagram of current exception model we have.

           =20

            Looking into the several issues we have against the exception m=
odel, it is worth considering a re-arrangement here.

http://issues.apache.org/jira/browse/AXISCPP-707

http://issues.apache.org/jira/browse/AXISCPP-721

http://issues.apache.org/jira/browse/AXISCPP-722

=20

            The idea is *very* simple here.  (basic OO stuff)

1.       We have m_sMessage and m_iExceptionCode as data members in all the=
 derived classes =E2=80=93 move them to base class. Move the access methods=
 to the base class as well.

2.       Drop all processException() methods and move the logic to construc=
tor

3.       getMessage() methods in the derived classes do not get the message=
 rather return the message corresponding to the exception code. Hence renam=
e getMessage() getMessageForExceptionCode()

4.       We have =E2=80=9Cwhat()=E2=80=9D in the base class to get the erro=
r message. This is a virtual method inherited from the =E2=80=98exception=
=E2=80=99 class hence we cannot change the naming. However, better to have =
a more sensible name like getMessage to wrap this

5.       There are too many constructors in the derived classes, I would li=
ke only two constructors for each class

a.       Copy constructor

b.       Constructor with 2 parameters, exception code and message, with me=
ssage defaulting to null. ExceptionClass(int code, char* msg =3D null)


> Overloaded processException in AxisEngineException class
> --------------------------------------------------------
>
>          Key: AXISCPP-722
>          URL: http://issues.apache.org/jira/browse/AXISCPP-722
>      Project: Axis-C++
>         Type: Bug
>   Components: Server - Engine
>     Versions: current (nightly)
>  Environment: All
>     Reporter: Dushshantha Chandradasa
>     Assignee: Dushshantha Chandradasa
>  Attachments: ExceptionModel_before.JPG
>
> Samisa Abeysinghe <samisa.abeysinghe@gmail.com> wrote on 30/06/2005
> > 11:04:29:
> >=20
> > > Hi All,
> > >     We have several overloaded forms of processException in=20
> > > AxisEngineException class.
> > >=20
> > >     I am sure that we are not using all of those. It is quite hard
> > to
> > > undestand and locate the problem locations when maintaining the=20
> > > implementation. Shall we drop those that are not used from the list=
=20
> > > below?
> > >=20
> > >     void processException(const exception* e);
> > >     void processException(const exception* e, const int
> > iExceptionCode);
> > >     void processException (const exception* e, char* pcMessage);
> > >     void processException(const int iExceptionCode);
> > >     void processException(const int iExceptionCode, char*
> > pcMessage);
> > >=20
> > >     BTW, some can be replaced with the copy constructor. I think we=
=20
> > > can drop the top 3 and keep the bottom 2. Sometime it is better to=20
> > > KISS ;-)
> > >=20
> > > Thanks,
> > > Samisa...

--=20
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