How to use exceptions

[Christian Köstlin]

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