Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:128286 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 70A7D1A00BC for ; Tue, 29 Jul 2025 07:15:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1753773218; bh=U9ZzUGxXSf0DHeiQbHmshGta/hxVrlCBaHx64KWP0GI=; h=References:In-Reply-To:From:Date:Subject:Cc:From; b=byuhBwlH11fKPW3rYiOlqgMGJ2iu+ES3sJP0HuJcEZQEiIaivqDzXuUP9fPI+/PvP Hu6e1zSSVtCb9Q9Z2KXO6YpZG/GrYruv/VTO3Z7gdfdlhdh3Lsg2Q9pGno+84/wjlh ecpkaxexvF6Z8kUzGxcM3oY+VhbUWq4H85vqU+19gIA9Yo4LU1heQjPCvp2Ih+Wb6D O5vZKaRcJ8Jc9B3Ad+Hyo9e0VXP+qOEmch7ivSswGQf3d1mHxSIllh/g84Daulgbxm DaBT6eA8wUbZoL2Sb6LjIfjBZ09VVwUqv5boZWKd8kwWuxk+p250hhws42AZjPf/bj WTb6+5gmeM7lw== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 67A3F1801D5 for ; Tue, 29 Jul 2025 07:13:36 +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=0.3 required=5.0 tests=BAYES_05,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,MALFORMED_FREEMAIL,MISSING_HEADERS,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,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 mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) (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 ; Tue, 29 Jul 2025 07:13:34 +0000 (UTC) Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-3b790dbb112so169691f8f.3 for ; Tue, 29 Jul 2025 00:15:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1753773316; x=1754378116; darn=lists.php.net; h=cc:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=U9ZzUGxXSf0DHeiQbHmshGta/hxVrlCBaHx64KWP0GI=; b=D7Jpj7Zbo3Z402UovdnfrCYH4oFhFrbOhICresxXCBtEGlU3ugSUj1V1X8J97BtCql dNoImRdFq5XzKUOp4nVldT4SSmiOO37I/cXpV8skpGDQ3GSr39hxHGvcRcgqmjFb6ItX 6tDl8klLk8MZKp+QYD/PbmzSaFkCn5g2UecysdHSkdvyCffGTxJ+noVCMxJbHtZvMquI 5PtYUnk0xtt4DX9ktSM6YqDFLcIiii4+y6NcSXo2imj4zHtYJbwmLOKTEJVHU77stAZQ lYD/St0G8waS74XTE//Xh1C6QbC0VWNEtfr1KycO/2MvrP5NMH+haRMBrVF/fIoF6dxh 83Pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753773316; x=1754378116; h=cc:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=U9ZzUGxXSf0DHeiQbHmshGta/hxVrlCBaHx64KWP0GI=; b=iXPg94tQAQNiohJ3P3/kO6ce+J5/zGdoa36HGkv/f7vASWSaqHQZKvzckPB4Q6uNWI nbeYnTLJLU8uESXqw3ZKHi1jI22s00Ij1w5ufzBxxWTH7iAg5pwyOaa/mTF3tvjzzeeJ jYmkmmEc48O5TkEifHZuYkg+WAVXovYM3BkKK2Y6Xdvb27HPRGYQplaeigKprBF4HFYR RI/k70gMHFPIFc0rzYTT385Zb1SshDxi44k+WfdKqGGJXFVaGXrbX8m8mKx1zjUV8Qmp D+jp3qBFUUYJcMbPc8B7dehtwkiPlVsLkKUAIqb/AbHBAP74rDtIrl/hQfI7ajyA3nBs Ka+g== X-Gm-Message-State: AOJu0YyD8fYyJtC8t8b9BS0MvczkKkkPnhhP8smDsGx84HZRe+sC2L4t 8Yvu2MJJ5wv5xTOxJJuvnSkEMrC4JB/QgO2Ia45CpLBsiIy4s9bdTsc8iUEGIXaJeRM/weCXDcG fB7HVIfhiLiVQj2eBJeD0sE3qDIe4mQXeLBeVnzg= X-Gm-Gg: ASbGncsbxeRnrooGADO6M41nsX34y+1TFbIb4UhbMB6tv1k+8izWOiHOx6XJ1lYME4O GQB+me2WrlIxytCRR3Nk6YsgiEYck9/OSySnFmwD/bbmPasVU8o26PsMdgIhV7GifmyLK1H8Nqv 5dg+LQ4Jk4o0i8e7WzqvGsfHFVw97wD9RKj/hXKCnQeGsrS2blS/nSzZvlzNQ6eUDWPu+NTisF2 qFuTdUuCWnZKNya X-Google-Smtp-Source: AGHT+IEzsrgOPzZIR0DSmaC3zYTNr9JprSEoxLtYDf/ZeNQI/2EG1BKnMMExRdo8SjSdVDt9h4syus4hBuUyTTfWlYc= X-Received: by 2002:a05:6000:144d:b0:3b7:58be:b0d with SMTP id ffacd0b85a97d-3b776664993mr11706160f8f.39.1753773315219; Tue, 29 Jul 2025 00:15:15 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 References: <7d83b833-6432-4a86-8e11-b4199fa92430@app.fastmail.com> In-Reply-To: Date: Tue, 29 Jul 2025 10:14:59 +0300 X-Gm-Features: Ac12FXyi9tSaHN8qx74cbds_jdFQWw7XCgDVvzb_EkxbAOp7neqtDi84yqlLFnA Message-ID: Subject: Re: [PHP-DEV] [DISCUSSION] User-land Throwable Cc: PHP internals Content-Type: multipart/alternative; boundary="0000000000007867da063b0c2b17" From: raveren@gmail.com (=?UTF-8?Q?Rokas_=C5=A0leinius?=) --0000000000007867da063b0c2b17 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 29 Jul 2025 at 01:53, Rob Landers wrote: > > > On Mon, Jul 28, 2025, at 19:54, Kamil Tekiela wrote: > > > > On Mon 28 Jul 2025, 20:50 Dmitry Derepko, wrote: > > > On Mon, Jul 28, 2025 at 3:26=E2=80=AFPM Rob Landers w= rote: > > > Wouldn=E2=80=99t a better approach be to allow serializing/deserializing > exceptions? > > =E2=80=94 Rob > > > It would look like another workaround to my case. Same as deserializing > data 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, > Dmitrii Derepko. > @xepozz > > > > > I still don't understand what real life use case this solves. Maybe you > 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 method= . > > > > I have a real life use case. I manage an SDK that does RPC. Exceptions > from 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 colleagu= es > do for the SDK other languages. > > Right now, I simply throw a SyntheticException which encapsulates the > original exception and displays the original stack trace as part of the > message, but if I could manipulate the stack trace, that would be much mo= re > useful to users who end up displaying the php stack trace instead of the > one from the remote system. Especially because a lot of frameworks like t= o > truncate messages for some reason that is unknown to me. > > At least, it would be nice to be able to create synthetic 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 Larry=E2=80=99s case. > > =E2=80=94 Rob > *=E2=80=BA exceptions that don=E2=80=99t need to get a stack trace from the= engine and could be 100% defined by the developer* FWIW, that totally solves all of my usecases I've ever encountered: `new Exception('my message', trace: $myTrace)` Now since we're talking, if \Exception had a setContext(array $context) + its getter, I'd be completely happy with it. That is emulated in the "userland" of Laravel internals - and it also goes along with PSR-3 which defines a logger interface as public function info($message, array $context =3D array()); And logging, to me at least, is in the same neighborhood as throwing exceptions - a lot of the time you want some attached data. *=E2=80=BA Disagree. Not all traces can be created locally by the engine. 3= rd-party traces are as useful as regular.* I think OP meant that there's an internal implementation reason for getTrace() to not be allowed to be overriden. --0000000000007867da063b0c2b17 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Tue, 29 Jul 2025 at 01:53, Rob Landers <rob@bottled.= codes> wrote:


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


On Mon 28 Jul 2025, 20:50 Dmitry Derepko, <xepozzd@gmail.com> wrote:

=
On Mon, Jul 28, 2025 at 3:26=E2=80=AFPM Rob Landers &= lt;rob@bottled.codes> wrote:
=
Wouldn=E2=80=99t a better approach be to allow serializing/d= eserializing exceptions?

=E2=80=94 Ro= b

It would look like anot= her workaround to my case. Same as deserializing data into a class to write= into a private property.
The simpler the=C2=A0better: just allow= users to set their own trace. Or not set it at all.

--
Best regards,
Dmitrii Derepko.



I still don't understand what real life us= e case this solves. Maybe you already explained it but I didn't get it.= IMHO the trace should be set by the engine and it should not be possible t= o overwrite the getTrace method.=C2=A0

I have a real life use case. I manage an SDK that does RPC. Ex= ceptions from 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 co= lleagues do for the SDK other languages.

Right now= , I simply throw a SyntheticException which encapsulates the original excep= tion and displays the original stack trace as part of the message, but if I= could manipulate the stack trace, that would be much more useful to users = who end up displaying the php stack trace instead of the one from the remot= e system. Especially because a lot of frameworks like to truncate messages = for some reason that is unknown to me.

At least, i= t would be nice to be able to create synthetic exceptions that don=E2=80=99= t need to get a stack trace from the engine and could be 100% defined by th= e developer =E2=80=94 or not, in Larry=E2=80=99s case.

=
=E2=80=94 Rob

=E2=80=BA exceptions=20 that don=E2=80=99t need to get a stack trace from the engine and could be 1= 00%=20 defined by the developer
FWIW, that = totally solves all of my usecases=C2=A0I've ever encountered: `new Exce= ption('my message', trace: $myTrace)`


Now since we're talking, if \Excepti= on had a setContext(array $con= text)=C2=A0+ its getter, I'd be completely happy with it.=C2=A0

That is emulated in= the=20 "userland" of Laravel internals - and it also goes along with PSR-3 whi= ch defines a logger interface as=C2=A0

public function info($message, arr= ay $context =3D array());
<= div style=3D"font-family:tahoma,sans-serif;font-size:small;color:rgb(102,51= ,0)" class=3D"gmail_default">
And lo= gging, to me at least, is in the same neighborhood as throwing exceptions -= a lot of the time you want some attached data.


=E2=80=BA Disagree. Not all traces can be created locally by the engine. 3rd-party tr= aces are as useful as regular.
I thi= nk OP meant that there's an internal implementation reason for getTrace= () to not be allowed to be overriden.
--0000000000007867da063b0c2b17--