On Friday, 12 August 2022 at 21:41:25 UTC, Christian Köstlin
wrote:
which would enable something like
```d
return s
.readText
.parseJSON
.contextWithException((UTFException e) {
return new Exception("Cannot process UTF-8 in
config file%s\n
On 13.08.22 15:00, kdevel wrote:
On Friday, 12 August 2022 at 21:41:25 UTC, Christian Köstlin wrote:
which would enable something like
```d
return s
.readText
.parseJSON
.contextWithException((UTFException e) {
return new Exception("Cannot process
On Saturday, 13 August 2022 at 13:36:08 UTC, Christian Köstlin
wrote:
[...]
1. error handling in main path: exactly thats what I would like
todo. but for that the errors that raise need to have
meaningful information. this is exactly what I am trying in
those context* functions ... they do
Quote from `src/druntime/src`:
```
/**
* Returns:
* A reference to the _next error in the list. This is used
when a new
* $(D Throwable) is thrown from inside a $(D catch) block.
The originally
* caught $(D Exception) will be chained to the new $(D
Throwable) via this
On 13.08.22 17:00, kdevel wrote:
"Exception enrichment" would be my wording which is supported by google
[1].
There is also the notion of "exception context" [2] and "contexted
exception" [3].
Thats really a good word! Especially it describes better what the java
guys are doing by adding
On 8/13/22 15:59, kdevel wrote:
> Quote from `src/druntime/src`:
>
> ```
> /**
> * Returns:
> * A reference to the _next error in the list. This is used when
a new
> * $(D Throwable) is thrown from inside a $(D catch) block. The
> originally
> * caught $(D
On Sunday, 14 August 2022 at 02:07:05 UTC, Ali Çehreli wrote:
This automatic "combining" of exceptions happens for cleanup
code like scope(exit). (I remember bug(s) for scope(failure).):
To be precise, an exception thrown inside a 'finally' block gets
chained onto the previous exception,
