Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.lang.php > #4035 > unrolled thread

SoapHeader direkt aus XML erstellen

Back to article view | Back to de.comp.lang.php

Contents

  SoapHeader direkt aus XML erstellen Ralph Stahl <post@rstahl.de> - 2017-01-25 19:56 +0100
    Re: SoapHeader direkt aus XML erstellen Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-01-26 23:59 +0100
      Re: SoapHeader direkt aus XML erstellen Ralph Stahl <post@rstahl.de> - 2017-01-27 09:56 +0100
        Re: SoapHeader direkt aus XML erstellen Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-01-27 12:14 +0100
          Re: SoapHeader direkt aus XML erstellen Ralph Stahl <post@rstahl.de> - 2017-01-27 14:39 +0100
            Re: SoapHeader direkt aus XML erstellen Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-01-27 14:47 +0100
              Re: SoapHeader direkt aus XML erstellen Ralph Stahl <post@rstahl.de> - 2017-01-27 15:10 +0100
                Re: SoapHeader direkt aus XML erstellen Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-01-27 16:40 +0100
                  Re: SoapHeader direkt aus XML erstellen Ralph Stahl <post@rstahl.de> - 2017-01-28 11:38 +0100
                    Re: SoapHeader direkt aus XML erstellen Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-01-28 12:04 +0100
                  Re: SoapHeader direkt aus XML erstellen "Christoph M. Becker" <cmbecker69@arcor.de> - 2017-01-28 12:22 +0100
                    Re: SoapHeader direkt aus XML erstellen Ralph Stahl <post@rstahl.de> - 2017-01-28 12:58 +0100
                    Re: SoapHeader direkt aus XML erstellen Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-01-28 13:35 +0100
                      Re: SoapHeader direkt aus XML erstellen "Christoph M. Becker" <cmbecker69@arcor.de> - 2017-01-28 16:52 +0100
                        Re: SoapHeader direkt aus XML erstellen Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-01-28 16:59 +0100
                    Re: SoapHeader direkt aus XML erstellen Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2017-01-28 14:22 +0000
                  Re: SoapHeader direkt aus XML erstellen Ralph Stahl <post@rstahl.de> - 2017-01-28 12:36 +0100
                    Re: SoapHeader direkt aus XML erstellen Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-01-28 13:37 +0100
                      Re: SoapHeader direkt aus XML erstellen Ralph Stahl <post@rstahl.de> - 2017-01-28 19:30 +0100
                        Re: SoapHeader direkt aus XML erstellen Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-01-28 21:10 +0100
                          Re: SoapHeader direkt aus XML erstellen Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2017-01-28 20:34 +0000
                            Re: SoapHeader direkt aus XML erstellen Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-01-28 22:10 +0100
                              Re: SoapHeader direkt aus XML erstellen Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2017-01-29 04:34 +0000
                                Re: SoapHeader direkt aus XML erstellen Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-01-29 14:29 +0100
                          Re: SoapHeader direkt aus XML erstellen Ralph Stahl <post@rstahl.de> - 2017-01-29 12:37 +0100
                            Re: SoapHeader direkt aus XML erstellen Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2017-01-29 11:55 +0000
                              Re: SoapHeader direkt aus XML erstellen Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-01-29 14:30 +0100
                                Re: SoapHeader direkt aus XML erstellen Ralph Stahl <post@rstahl.de> - 2017-01-30 09:43 +0100

Page 2 of 2 — ← Prev page 1 [2]

#4059

On Sat, 28 Jan 2017 21:10:05 Thomas 'PointedEars' Lahn wrote:
> Der Stacktrace führte Dich (und uns) eben zur *tatsächlich* den Fehler 
> erzeugenden Zeile, wenn Du das Exception-Handling *deaktivieren* würdest, 
> d. h. die Zeilen mit “try” und “catch” *auskommentierst*:
> 
>   // try {
>     /* blubb */
>   // } catch (…) {
>     echo 'Fehler: ' . $e->getMessage();
>   // }

Oder, falls er weiter oben noch einen oder gar mehrere Exception-Handler
hat, die er erst deaktivieren müsste, ein simples:

| var_dump($e); die;

Ist nicht gerade elegant, reicht aber für den Zweck.

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan - weiter, standhaft in allen Fluten!
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#4060

Stefan Froehlich wrote:

> On Sat, 28 Jan 2017 21:10:05 Thomas 'PointedEars' Lahn wrote:
>> Der Stacktrace führte Dich (und uns) eben zur *tatsächlich* den Fehler
>> erzeugenden Zeile, wenn Du das Exception-Handling *deaktivieren* würdest,
>> d. h. die Zeilen mit “try” und “catch” *auskommentierst*:
>> 
>>   // try {
>>     /* blubb */
>>   // } catch (…) {
>>     echo 'Fehler: ' . $e->getMessage();
>>   // }
> 
> Oder, falls er weiter oben noch einen oder gar mehrere Exception-Handler
> hat, die er erst deaktivieren müsste, ein simples:
> 
> | var_dump($e); die;
> 
> Ist nicht gerade elegant, reicht aber für den Zweck.

Hast Du das getestet?

$ php -r 'xdebug_disable(); try { throw new SoapFault(); } catch (Exception 
$e) { var_dump($e); die; }'

sagt mir, dass das nicht in jedem Fall reicht, weil nur die von Xdebug 
hinzugefügte Eigenschaft “xdebug_message” den Stacktrace direkt enthält.

Daher wäre mindestens noch ein Aufruf von Exception::getTrace() oder 
Exception::getTraceAsString() oder ein Typecast nach string (um einfach 
Exception::__toString() aufzurufen) nötig.

Das ist tatsächlich mal ein Vorteil von “echo” gegenüber var_dump(): es 
konvertiert das Argument implizit zu string, so dass man sich den expliziten 
Typecast sparen kann.  “echo $e; die;”.

-- 
PointedEars
Zend Certified PHP Engineer <http://www.zend.com/en/yellow-pages/ZEND024953>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#4061

On Sat, 28 Jan 2017 22:10:44 Thomas 'PointedEars' Lahn wrote:
> Stefan Froehlich wrote:
> > | var_dump($e); die;
> > 
> > Ist nicht gerade elegant, reicht aber für den Zweck.
> 
> Hast Du das getestet?

An sich schon, aber...
 
> $ php -r 'xdebug_disable(); try { throw new SoapFault(); } catch (Exception 
> $e) { var_dump($e); die; }'
 
> sagt mir, dass das nicht in jedem Fall reicht, weil nur die von Xdebug 
> hinzugefügte Eigenschaft “xdebug_message” den Stacktrace direkt enthält.

Hm, ja. Ich habe hier xdebug immer mit dabei und nicht daran gedacht,
dass sich var_dump damit anders verhält, sorry.

Servus,
   Stefan 

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Das große Entzücken! Stefan, wenn der kleine Arger kocht!
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#4064

Stefan Froehlich wrote:

> On Sat, 28 Jan 2017 22:10:44 Thomas 'PointedEars' Lahn wrote:
>> $ php -r 'xdebug_disable(); try { throw new SoapFault(); } catch
>> (Exception $e) { var_dump($e); die; }'
>  
>> sagt mir, dass das nicht in jedem Fall reicht, weil nur die von Xdebug
>> hinzugefügte Eigenschaft “xdebug_message” den Stacktrace direkt enthält.
> 
> Hm, ja. Ich habe hier xdebug immer mit dabei und nicht daran gedacht,
> dass sich var_dump damit anders verhält, sorry.

AISB: Die Ursache dafür, dass mit Xdebug der Stacktrace mit var_dump($e) zu 
sehen ist, ist _nicht_ Xdebugs Modifikation von var_dump(), sondern Xdebugs 
Modifikation von Exception:

$ php -r 'function f () { try { throw new Exception(); } catch (Exception 
$e) { echo $e->xdebug_message; }}; f();
xdebug_disable(); f();'
PHP Warning:  Module 'PDO' already loaded in Unknown on line 0
PHP Warning:  Module 'vld' already loaded in Unknown on line 0

Exception:  in Command line code on line 1

Call Stack:
    0.0001     234848   1. {main}() Command line code:0
    0.0001     234896   2. f() Command line code:1


Variables in local scope (#2):
  $e = *uninitialized*
PHP Notice:  Undefined property: Exception::$xdebug_message in Command line 
code on line 1

-- 
PointedEars
Zend Certified PHP Engineer <http://www.zend.com/en/yellow-pages/ZEND024953>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#4062

Thomas 'PointedEars' Lahn schrieb:
> Ralph Stahl wrote:
> 
>> Thomas 'PointedEars' Lahn schrieb:
>>> Ralph Stahl wrote:
>>>> Thomas 'PointedEars' Lahn schrieb:
>>>>> Ralph Stahl wrote:
>>>>>> Mehr steht nicht infolge
>>>>>>
>>>>>> } catch(SoapFault $e) {
>>>>>>     echo 'Fehler: ' . $e->getMessage();
>>>>>> }
>>>>>
>>>>> Deaktivier das nächste Mal Exception-Handling und poste die Exception –
>>>>> nicht das, was Du daraus machst.
>>>>
>>>> [faultstring] =>  "Unknown Method"
>>>> [faultcode] => "SOAP-ENV:Server"

[...]

> Der Stacktrace führte Dich (und uns) eben zur *tatsächlich* den Fehler 
> erzeugenden Zeile, wenn Du das Exception-Handling *deaktivieren* würdest, 
> d. h. die Zeilen mit “try” und “catch” *auskommentierst*:
> 
>   // try {
>     /* blubb */
>   // } catch (…) {
>     echo 'Fehler: ' . $e->getMessage();
>   // }
> 
> Das ist in PHP nicht wesentlich anders als in anderen Programmiersprachen, 
> die Exceptions unterstützen.
> 

Woher kommt das $e, wenn es kein catch(Exception $e) gibt?

Ich habe es jetzt mal gelassen wie es war und einfach nur ein "echo $e"
hingeschrieben - interessant, dachte nicht, dass das geht! Das Ergebnis
lässt mich aufhorchen:

SoapFault exception: [SOAP-ENV:Server] Unknown Method in
/home/.../test2.php:106 Stack trace: #0 /home/.../test2.php(106):
SoapClient->__soapCall('Funktion', Array) #1 {main}

Folgende 2 Erkenntnisse:

$header = new SoapHeader(
    $tns,
    'Header',
    new SoapVar(
        new SoapVar($xml, XSD_ANYXML),
        SOAP_ENC_OBJECT
    )
);

$client->__setSoapHeaders($header);

ist nicht die Fehlerquelle, sondern der nachfolgende Aufruf der
"Nutzfunktion"

$result = $client->__soapCall(
    'Funktion',
    array(
        'Header' => $header,
        'param' => $wert    // Zeile 106
    )
);

Na gugge! Da wurde mir doch eine ganz andere Stelle vorgegaukelt. Da bin
ich zwar beruhigter, habe aber eine neue Baustelle. So ist das leben.
Den richtigen Aufruf der 'Funktion' werde ich woh aus dem WSDL-File
rauskriegen (wsdl2php oder so), aber erst nächste Woche :-).

Ralph

[toc] | [prev] | [next] | [standalone]

#4063

On Sun, 29 Jan 2017 12:37:01 Ralph Stahl wrote:
> Thomas 'PointedEars' Lahn schrieb:
> >   // try {
> >     /* blubb */
> >   // } catch (…) {
> >     echo 'Fehler: ' . $e->getMessage();
> >   // }
 
> > Das ist in PHP nicht wesentlich anders als in anderen
> > Programmiersprachen, die Exceptions unterstützen.
 
> Woher kommt das $e, wenn es kein catch(Exception $e) gibt?

So weit wird der Code gar nicht erst ausgeführt - wenn Du die Exception
nicht mit try-catch abfängst, wird sie nach oben weitergereicht und
führt (so nicht irgendwo weiter oben noch ein catch-try Block existiert)
letztlich zum Programmabbruch.

Klar, ohne den eigentlichen Fehler würdest Du dann einen Fehler beim
echo bekommen.
 
Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan. Für weiche Drüsen, in den Stunden der Freude!
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#4065

Stefan Froehlich wrote:

> On Sun, 29 Jan 2017 12:37:01 Ralph Stahl wrote:
>> Thomas 'PointedEars' Lahn schrieb:
>> >   // try {
>> >     /* blubb */
>> >   // } catch (…) {
>> >     echo 'Fehler: ' . $e->getMessage();
^^^^^^^^^^
>> >   // }
>  
>> > Das ist in PHP nicht wesentlich anders als in anderen
>> > Programmiersprachen, die Exceptions unterstützen.
>  
>> Woher kommt das $e, wenn es kein catch(Exception $e) gibt?
> 
> So weit wird der Code gar nicht erst ausgeführt - wenn Du die Exception
> nicht mit try-catch abfängst, wird sie nach oben weitergereicht und
> führt (so nicht irgendwo weiter oben noch ein catch-try Block existiert)
> letztlich zum Programmabbruch.
> 
> Klar, ohne den eigentlichen Fehler würdest Du dann einen Fehler beim
> echo bekommen.

Stimmt, diese Zeile muss dann natürlich ebenfalls auskommentiert werden.
Mein Fehler.

-- 
PointedEars
Zend Certified PHP Engineer <http://www.zend.com/en/yellow-pages/ZEND024953>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#4066

Thomas 'PointedEars' Lahn schrieb:
> Stefan Froehlich wrote:
> 
>> On Sun, 29 Jan 2017 12:37:01 Ralph Stahl wrote:
>>> Thomas 'PointedEars' Lahn schrieb:
>>>>   // try {
>>>>     /* blubb */
>>>>   // } catch (…) {
>>>>     echo 'Fehler: ' . $e->getMessage();
> ^^^^^^^^^^
>>>>   // }
>>  
>>>> Das ist in PHP nicht wesentlich anders als in anderen
>>>> Programmiersprachen, die Exceptions unterstützen.
>>  
>>> Woher kommt das $e, wenn es kein catch(Exception $e) gibt?
>>
>> So weit wird der Code gar nicht erst ausgeführt - wenn Du die Exception
>> nicht mit try-catch abfängst, wird sie nach oben weitergereicht und
>> führt (so nicht irgendwo weiter oben noch ein catch-try Block existiert)
>> letztlich zum Programmabbruch.
>>
>> Klar, ohne den eigentlichen Fehler würdest Du dann einen Fehler beim
>> echo bekommen.
> 
> Stimmt, diese Zeile muss dann natürlich ebenfalls auskommentiert werden.
> Mein Fehler.
> 

Ist doch gar nicht schlecht: mit try/catch liefert mir "echo $e" mehr
Info als das übliche "echo $e->getMessage()", nämlich den Stacktrace :-).

Ralph

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | de.comp.lang.php

csiph-web