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 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
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 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 12.08.22 23:05, Christian Köstlin wrote:
On 12.08.22 01:50, H. S. Teoh wrote:
...
>
The OP's idea of wrapping throwing code with a function that tacks on
extra information is a good idea. Perhaps the use of strings isn't
ideal, but in principle I like his idea of exceptions acquiring
On 12.08.22 01:50, H. S. Teoh wrote:
...
>
The OP's idea of wrapping throwing code with a function that tacks on
extra information is a good idea. Perhaps the use of strings isn't
ideal, but in principle I like his idea of exceptions acquiring
higher-level information as it propagates up the
On Friday, 12 August 2022 at 00:40:48 UTC, H. S. Teoh wrote:
Hmm! That gets me thinking. Maybe something like this?
aye. and scopes share dtors which means we can do it in the lib
today:
---
struct AdditionalInfo {
static string[] info;
this(string info) {
On Fri, Aug 12, 2022 at 12:12:13AM +, Adam D Ruppe via Digitalmars-d-learn
wrote:
> On Thursday, 11 August 2022 at 23:50:58 UTC, H. S. Teoh wrote:
> > I think the OP's idea is somewhat different: adding contextual
> > information to a propagating exception that the throwing code may
> > not
On Thursday, 11 August 2022 at 23:50:58 UTC, H. S. Teoh wrote:
I think the OP's idea is somewhat different: adding contextual
information to a propagating exception that the throwing code
may not have access to.
Yeah, but you can use the mechanism again: you'd catch the one
then throw a new
On Thu, Aug 11, 2022 at 11:06:45PM +, Adam D Ruppe via Digitalmars-d-learn
wrote:
> You might find my recent blog post interesting too:
>
> http://dpldocs.info/this-week-in-d/Blog.Posted_2022_08_01.html#exception-template-concept
>
> and a draft of some more concepts:
>
On 12.08.22 01:06, Adam D Ruppe wrote:
You might find my recent blog post interesting too:
http://dpldocs.info/this-week-in-d/Blog.Posted_2022_08_01.html#exception-template-concept
and a draft of some more concepts:
http://arsd-official.dpldocs.info/source/arsd.exception.d.html
I also find
You might find my recent blog post interesting too:
http://dpldocs.info/this-week-in-d/Blog.Posted_2022_08_01.html#exception-template-concept
and a draft of some more concepts:
http://arsd-official.dpldocs.info/source/arsd.exception.d.html
I also find the lack of information disturbing, but I
Dear d-lang experts,
lets say in general I am quite happy with exceptions.
Recently though I stumbled upon two problems with them:
1. Its quite simple to loose valuable information
2. Its hard to present the exception messages to end users of your
program
Let me elaborate on those:
Lets take
13 matches
Mail list logo
