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 UTF-8 in config file%s\n  %s".format(s, e.msg), e);
>>         })
>>         .contextWithException((FileException e) {
>>             return new Exception("Cannot process config file%s\n %s".format(s, e.msg), e);
>>         });
>> ```
> 
> This is not as DRY as it could be. Furthermore I would try implement the error handling completely outside the main execution path, ideally in a wrapper around a the old main function (renamed to main_). This approach becomes problematic if exceptions of the same class can be thrown from two functions of the chain. >
> Your code is printing e.msg. How to you localize that string?
Those 3 points are exactly touching the problems (I am ignoring the DRY thing for now, as this is a side battle):
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 not do error handling, but more something like error enhancement (by fixing up the error information).
2. yes ... for that the chain would need to be broken up, then you can react on the same exception classes of different members of the chain differently ... for that I do not see a nice way to write it in d.
3. localization is a fantastic example of data that needs to be added to almost every exception that raises from below. my example with the strings is just an example, it could also be that by conventions of your application framework all context* functions raise LocalizableExceptions, that somehow can then be mapped to different languages with their own api. the generalalized main function then would handle those exception classes differently from "normal" exceptions.

hope that makes sense.

kind regards,
christian

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 not do error handling, but more something like error enhancement (by fixing up the error information).

"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].

> 2. yes ... for that the chain would need to be broken up, then you can react on the same exception classes of different members of the chain differently ... for that I do not see a nice way to write it in d.

The current filename imposes a context on its processing. The exception thrown from readText knows that filename and propagates it within the exception msg. Unfortunately exceptions are frequently only "stringly typed", e.g.

394: throw new JSONException("JSONValue is not a number type");
406: throw new JSONException("JSONValue is not a an integral type");

This should have been made into an exception hierarchy with the faulty value beeing a data member of the respective class. That would nicely support the crafting of a message for the user in the presentation layer.

Of course the UTF8Exception must be enriched with the filename in the application code.

> 3. localization is a fantastic example of data that needs to be added to almost every exception that raises from below.

How would you handle a FileException.msg = "myconfig.cnf: Permission denied"? Run regular expressions over the msg? Something is fundamentally wrong if any kind of parsing of error strings is required.

Then there is another type of user who shall not be faced with any kind of specific error message: The client of a company which runs a web application. This case is easy to implement: Catch any Exception and replace it with an "The Unforeseen happend, id#" message. Leave the code as it is and let the stack trace go into the error_log. The devops people of the company probably understand english messages.


[1] https://jenkov.com/tutorials/java-exception-handling/exception-enrichment.html

[2] https://docs.microsoft.com/en-us/dotnet/api/system.web.mvc.exceptioncontext?view=aspnet-mvc-5.2

[3] https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/exception/ContextedException.html

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 information to an existing object and
rethrowing, without creating a new exception, covering the tracks of the
original exception by wrapping it and throwing this.
Can we have that for dlang exceptions as well (I mean as additional api
in the baseclass)? It would not break old code, as it would be
additional api?

> The current filename imposes a context on its processing. The exception thrown from readText knows that filename and propagates it within the exception msg. Unfortunately exceptions are frequently only "stringly typed", e.g.
yes .. thats a shame. I think it is, because its much shorter than
defining a new member, a new constructor, a new message method in the
new exception subclass.

> 
> 394: throw new JSONException("JSONValue is not a number type");
> 406: throw new JSONException("JSONValue is not a an integral type");
> 
> This should have been made into an exception hierarchy with the faulty value beeing a data member of the respective class. That would nicely support the crafting of a message for the user in the presentation layer.
I do agree.

> Of course the UTF8Exception must be enriched with the filename in the application code.
I do not agree. As for me it looks like `readText` works with kind of
two API's internally. One is the file API that can throw, and forwards
information nicely (about which file has the problem). And then some
UTF-8 processing based on data from that file (which should also forward
the information of the file, as the end user of this API did not even
touch a file at all (only a string representing a filename)).
But for sure there are different scenarios where the enrichment needs to
happen at call site.

>> 3. localization is a fantastic example of data that needs to be added to almost every exception that raises from below.
> 
> How would you handle a FileException.msg = "myconfig.cnf: Permission denied"? Run regular expressions over the msg? Something is fundamentally wrong if any kind of parsing of error strings is required.
Thats what I mean with "that raises from below". I think the
FileException is not supposed to be on the top of the exception stack,
but a more application level exception (e.g. Cannot process
configuration file (as Configuration file is something on application
level)).

> Then there is another type of user who shall not be faced with any kind of specific error message: The client of a company which runs a web application. This case is easy to implement: Catch any Exception and replace it with an "The Unforeseen happend, id#" message. Leave the code as it is and let the stack trace go into the error_log. The devops people of the company probably understand english messages.
One could argue, that every exception stacktrace that comes to
stdout/-err or a user interface is already a bug. It might be helpful
for developers and system administrators, but not for end users. So your
solution is perhaps inconvinient for developers, but good in general.


> [1] https://jenkov.com/tutorials/java-exception-handling/exception-enrichment.html
> 
> [2] https://docs.microsoft.com/en-us/dotnet/api/system.web.mvc.exceptioncontext?view=aspnet-mvc-5.2
> 
> [3] https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/exception/ContextedException.html

thanks again for the links ... nice read!!!

Kind regards,
Christian