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