Re:How We Centralized and Structured Error Handling in Golang
by int_19h on Wednesday December 18, 2024 @01:11PM
(#42453151)
The problem is that there's no way to specify an exception specification like "I propagate everything that this lambda throws" (or, for generics, "that method M of class C throws").
[ Parent
| on HN ]
Re:How We Centralized and Structured Error Handling in Golang
by layer8 on Wednesday December 18, 2024 @07:44PM
(#42457149)
No, but you can have an interface like
interface Func<P, R, X extends Exception>
{
R func(P param) throws X;
}
or the same with more than one exception type, and convert your lambda to that. This works. The only problem is that you can’t abstract over an arbitrary number of exception types.In principle, one could imagine a syntax for variadic type parameters like
interface Func<P..., R, X... extends Exception>
{
R func(P... params) throws X...;
}
that would solve that problem.
Re:How We Centralized and Structured Error Handling in Golang
by erik_seaberg on Wednesday December 18, 2024 @11:37PM
(#42458468)
Will the compiler infer that a lambda or a method ref implements Func with its exception type param, or do you have to rewrite call sites?
Re:How We Centralized and Structured Error Handling in Golang
by layer8 on Thursday December 19, 2024 @04:36PM
(#42465930)
The compiler already infers that in current Java for one checked exception type, and also for several exception types at least in some cases (the latter seems to be a little more buggy in the current implementation).