Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:128282 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by lists.php.net (Postfix) with ESMTPS id 2A02C1A00BC for ; Mon, 28 Jul 2025 22:50:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1753742926; bh=VDelDczENLPKHxVd10MyfC077/wEQPUKlQpNnBJWYlY=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=If1UUzvZhlCLMGvEKM8BDjCTAZXvALyd89v+g2Wu3rUHPxttsbYb31OshcFnLcJLb HDCb/8fmxBeC8FukYLE8Krt1I3Ng4Vd578uQRH1Q73QKuqnE1hc6aDhqfLqZvyPx5n ahsA/E3S6wzsaxgZr3+Eml2phTVYHBZbAT9jTTztq9LbAmFzYK/R0vppgA0xrar9CM lb4canymZ/7hq6lNcM26T6Z9RxOZevJnMx/c1qwn6mLZlIbKCyZtJ9YnJHizwn6XJD KBkDig4e85sQnKJmnR3y+UVa+q9xTgo1r3Nj7LEK4724uinaA+mKWxfGAJAOkYLjGv 9JDYA4wNX+jnQ== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id EA34D180079 for ; Mon, 28 Jul 2025 22:48:45 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_MISSING,HTML_MESSAGE, RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) X-Envelope-From: Received: from fhigh-b1-smtp.messagingengine.com (fhigh-b1-smtp.messagingengine.com [202.12.124.152]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 28 Jul 2025 22:48:45 +0000 (UTC) Received: from phl-compute-05.internal (phl-compute-05.phl.internal [10.202.2.45]) by mailfhigh.stl.internal (Postfix) with ESMTP id 200047A0BC4; Mon, 28 Jul 2025 18:50:28 -0400 (EDT) Received: from phl-imap-05 ([10.202.2.95]) by phl-compute-05.internal (MEProxy); Mon, 28 Jul 2025 18:50:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bottled.codes; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm1; t=1753743027; x= 1753829427; bh=VDelDczENLPKHxVd10MyfC077/wEQPUKlQpNnBJWYlY=; b=j oChwjSsM/SJadraJLTFENyaVJhDuo6+kks4M7GziSsm2Llu+mq1pd8bJ9IWVG+3v PZMB1hdj/jH2iVvn+0Pud2FZ2zW1ZthhdXXqiYTdM1xciD7XSMGsPbaVm7n/iE15 p02upilg/dcbiSThXue3/3FI2r3JqG7w/QDlRYSwuqb1sD2n3rsEgUc40C2Yx7Ps 56UmTFjR6Vwd+8YnpNfxb/0UqV71NxnhDw75M2LlOfM30MyDHvCEAEQwHBr2zKCN PB/6Spxo6yssn69ArO0flGzTWJA95gcpaQlMIUTVBwjDCck7q7cEvzj1TyWggnlH J/e2H2PvHSr2iB4QTosTA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1753743027; x=1753829427; bh=VDelDczENLPKHxVd10MyfC077/wEQPUKlQp NnBJWYlY=; b=SYImKXgwdlLtIXpKq/OzS0vJEzUjMDNya/KCBUOaFeHv1B9sbk0 1ptfCTxJNfN9bHy0GpI1FRIp4hzR63MMc2rj8HxTcQYsMDLTn+Hhjk5t1zIxHLea aru6oG4Q0ZG2vWXtFV1Nm0DAojSdvSYdrKim7qbL86LkrYBvl3+K9tyLyWVHA+Bd PLzJrF35vxM9LF6HSj+fR/KMEUECUUuqhlrReyKLX3AvNvr9w+tSvOjSi5bDSg2j wj+bTHNt5pTwUv/Zux7tgPyIGQDxTYMC4d3xwytrjnTk2vaJ4GMabPuLgxWtbAXu vzCocZrMyKbgDspKLa0DIaCvYKLlEwnZ83A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdelfeegvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefoggffhffvvefkjghfufgtsegrtderreertdejnecuhfhrohhmpedftfhosgcunfgr nhguvghrshdfuceorhhosgessghothhtlhgvugdrtghouggvsheqnecuggftrfgrthhtvg hrnhepieeuteehvddvfeejhffgieehleehhedthfefkeejffelgfevvdekudetjeejtddt necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprhhosg essghothhtlhgvugdrtghouggvshdpnhgspghrtghpthhtohepfedpmhhouggvpehsmhht phhouhhtpdhrtghpthhtohepthgvkhhivghlrgdvgeeisehgmhgrihhlrdgtohhmpdhrtg hpthhtohepgigvphhoiiiiugesghhmrghilhdrtghomhdprhgtphhtthhopehinhhtvghr nhgrlhhssehlihhsthhsrdhphhhprdhnvght X-ME-Proxy: Feedback-ID: ifab94697:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 96B041820074; Mon, 28 Jul 2025 18:50:27 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 X-ThreadId: T75a531484929f33e Date: Tue, 29 Jul 2025 00:50:00 +0200 To: "Kamil Tekiela" , "Dmitry Derepko" Cc: "PHP internals" Message-ID: In-Reply-To: References: <7d83b833-6432-4a86-8e11-b4199fa92430@app.fastmail.com> Subject: Re: [PHP-DEV] [DISCUSSION] User-land Throwable Content-Type: multipart/alternative; boundary=fc8ae8d236314fb4814723c4b1dcb0b1 From: rob@bottled.codes ("Rob Landers") --fc8ae8d236314fb4814723c4b1dcb0b1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Mon, Jul 28, 2025, at 19:54, Kamil Tekiela wrote: >=20 >=20 > On Mon 28 Jul 2025, 20:50 Dmitry Derepko, wrote: >>=20 >> On Mon, Jul 28, 2025 at 3:26=E2=80=AFPM Rob Landers wrote: >>>=20 >>> Wouldn=E2=80=99t a better approach be to allow serializing/deseriali= zing exceptions? >>>=20 >>> =E2=80=94 Rob >>=20 >> It would look like another workaround to my case. Same as deserializi= ng data into a class to write into a private property. >> The simpler the better: just allow users to set their own trace. Or n= ot set it at all. >>=20 >> -- >> Best regards, >> Dmitrii Derepko. >> @xepozz >=20 >=20 >=20 > I still don't understand what real life use case this solves. Maybe yo= u already explained it but I didn't get it. IMHO the trace should be set= by the engine and it should not be possible to overwrite the getTrace m= ethod.=20 >>=20 I have a real life use case. I manage an SDK that does RPC. Exceptions f= rom remote services are normalized no matter the language of the RPC. It= would be nice to turn these into real exceptions like some of my collea= gues do for the SDK other languages. Right now, I simply throw a SyntheticException which encapsulates the or= iginal exception and displays the original stack trace as part of the me= ssage, but if I could manipulate the stack trace, that would be much mor= e useful to users who end up displaying the php stack trace instead of t= he one from the remote system. Especially because a lot of frameworks li= ke to truncate messages for some reason that is unknown to me. At least, it would be nice to be able to create synthetic exceptions tha= t don=E2=80=99t need to get a stack trace from the engine and could be 1= 00% defined by the developer =E2=80=94 or not, in Larry=E2=80=99s case. =E2=80=94 Rob --fc8ae8d236314fb4814723c4b1dcb0b1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jul 28, 2025, at 19:54, Kamil Tekiela wrote:


On Mon 28 Jul 20= 25, 20:50 Dmitry Derepko, <xepoz= zd@gmail.com> wrote:

<= /div>
On Mon, Jul 28, 2025 at 3:26=E2=80=AFPM Rob Landers <rob@bottled.= codes> wrote:

Wouldn=E2=80=99t a better= approach be to allow serializing/deserializing exceptions?
=E2=80=94 Rob

I= t would look like another workaround to my case. Same as deserializing d= ata into a class to write into a private property.
The simpler= the better: just allow users to set their own trace. Or not set it= at all.

--
Best regards,
Dmitr= ii Derepko.

=


I still don't understand what real life use case this solves. Maybe yo= u already explained it but I didn't get it. IMHO the trace should be set= by the engine and it should not be possible to overwrite the getTrace m= ethod. 

=
I have a real life use case. I manage an SDK that does RP= C. Exceptions from remote services are normalized no matter the language= of the RPC. It would be nice to turn these into real exceptions like so= me of my colleagues do for the SDK other languages.

=
Right now, I simply throw a SyntheticException which encapsulates t= he original exception and displays the original stack trace as part of t= he message, but if I could manipulate the stack trace, that would be muc= h more useful to users who end up displaying the php stack trace instead= of the one from the remote system. Especially because a lot of framewor= ks like to truncate messages for some reason that is unknown to me.

At least, it would be nice to be able to create syn= thetic exceptions that don=E2=80=99t need to get a stack trace from the = engine and could be 100% defined by the developer =E2=80=94 or not, in L= arry=E2=80=99s case.

=E2=80= =94 Rob
--fc8ae8d236314fb4814723c4b1dcb0b1--