New Exception constructor is optional only.
I think the conflicts should only be there when some change is made in
the error messages which are already migrated.

On Mon, 29 Jun 2026 at 14:10, Daan Hoogland <[email protected]> wrote:
>
> good point,
>
> On Mon, Jun 29, 2026 at 10:05 AM Abhishek Kumar <[email protected]> wrote:
> >
> > Thanks Daan.
> >
> > Moving to main/4.24 is not a problem. Though I've some changes in the
> > draft to use the new exception creation structure for VM-related
> > operations (mainly in classes: UserVmManagerImpl,
> > UnmanagedVMsManagerImpl, VirtualMachineManagerImpl).
> > With about 700 occurrences, I'm concerned they will cause regular
> > merge conflicts until the 4.20/4.22 EOL.
> > I'll move the changes to target main branch for now and see how it goes.
>
> maybe we can split the PR into the structural bit and the utility, Or
> make the use of the new Exception constructor optional?
>
> >
> > Regards,
> > Abhishek
> >
> > On Fri, 26 Jun 2026 at 13:37, Daan Hoogland <[email protected]> wrote:
> > >
> > > hey Abhishek,
> > > not much reaction yet. I like the idea and think, as this is out of
> > > scope for the initial work, we should plan to convert error reporting
> > > after this is in.
> > > one remark. Your PR is targeting 22, is 24 more in order?
> > >
> > > On Wed, Jun 17, 2026 at 8:30 AM Abhishek Kumar <[email protected]> 
> > > wrote:
> > > >
> > > > Hi all,
> > > >
> > > > I would like to seek feedback from the community on a framework-level
> > > > improvement around API error handling, consistency, customization, and
> > > > localization in CloudStack.
> > > >
> > > > The goal of this effort is to provide a more structured and consistent
> > > > approach to error reporting while maintaining backward compatibility 
> > > > with
> > > > existing API clients. The proposal introduces stable error message keys,
> > > > structured metadata, customizable message templates, and support for
> > > > localized and role-aware error messages.
> > > >
> > > > The design proposal is available here:
> > > >
> > > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Error+Message+Consistency%2C+Customization%2C+and+Localization+Framework
> > > >
> > > > A reference implementation is available in the following PR:
> > > >
> > > > https://github.com/apache/cloudstack/pull/12336
> > > >
> > > > Given that this is a framework-level change that could influence how 
> > > > errors
> > > > are surfaced across CloudStack APIs going forward, I would appreciate
> > > > feedback on the overall design and architecture before proceeding 
> > > > further.
> > > >
> > > > Comments, suggestions, concerns, or alternative approaches are all 
> > > > welcome.
> > > >
> > > > Thanks,
> > > > Abhishek
> > >
> > >
> > >
> > > --
> > > Daan
>
>
>
> --
> Daan

Reply via email to