[prev in list] [next in list] [prev in thread] [next in thread] 

List:       axis-c-dev
Subject:    Re: Exception handling and fault mapping
From:       damitha () opensource ! lk
Date:       2004-05-25 7:23:21
Message-ID: 35900.220.247.240.17.1085469801.squirrel () 220 ! 247 ! 240 ! 17
[Download RAW message or body]

Hi John,

>
> One question - what does this mean?
> /* MustUnderstand faults */
>     SOAP_MUSTUNDERSTAND,
>
If a node can't process a soap header intended for it, it should send a
soap must understand fault.
for example in ServerAxisEngine class

         /*
         * Before processing the soap body check whether there is any header
         * blocks with mustUnderstand attribute left unprocessed in the
         * Deserializer. If so return a soap fault.
         */
        if (m_pDZ->isAnyMustUnderstandHeadersLeft ())
        {
            AXISTRACE1("SOAP_MUSTUNDERSTAND", CRITICAL);
            THROW_AXIS_SOAP_EXCEPTION(SOAP_MUSTUNDERSTAND);
...............
...............



>
> Also, I think this document mixes up faults and exceptions doesn't it? For
> instance the "fault codes" - are these actually exceptions that can
> happen?
You are right. It's kind of a mixing of soap faults and exceptions that
could happen in the server side. But it has reasons.
If an exception occur in the server library that the library itself cannot
resolve it need to propagte that information to somebody who might can
handler it properly and do accordingly. For example if the server cannot
load a service library because library is not placed in a place that the
server can "see" it what the server do is it throws an exception saying
that
it cannot load the library.
...
...

if (!pHandlerInfo->m_Handler)
    {
        AXISTRACE1("DLOPEN FAILED", CRITICAL);
        THROW_AXIS_ENGINE_EXCEPTION(SERVER_ENGINE_LIBRARYLOADINGFAILED);
    }

...
...

 That information should go to the client who requested for the service.
faultcode should be "Server" faultactor is the url which the service is
running. in the faultdetail the reason should be included.
But if the server have all the knowledge necessary to handle the exception
and succeed without failing then it should handle it without propagting to
the client as a soap fault. Such kind of exceptions can be added to the
AXISC_EXCEPTIONS enumeration with the
AXISC_ perfix.
for example if the server cannot read the logpath from the configuration
file it can still proceed by taking the default log path value. In such of
an instance when the reading from the conf fails it can throw something
like
THROW_AXIS_CONFIG_EXCEPTION(AXISC_READCONF_EXCEPTION)

thanks
damitha





>
> thanks,
> John.
>
>
>
>
>
>              damitha@opensourc
>              e.lk
>                                                                         To
>              24/05/2004 09:45          axis-c-dev@ws.apache.org
>                                                                         cc
>
>              Please respond to                                     Subject
>               "Apache AXIS C           Exception handling and fault
>              Developers List"          mapping
>
>
>
>
>
>
>
>
>
>
> Hi,
>     I'm working on exception handling and fault mapping of the Axis C++
> engine. Attached is a rough design of the work I'm doing.
> Please send any feed back.
>
> thanks
> damitha(See attached file: exception_design)

[prev in list] [next in list] [prev in thread] [next in thread]