[HN Gopher] Comparing Exceptions and Errors in D
       ___________________________________________________________________
        
       Comparing Exceptions and Errors in D
        
       Author : mhh__
       Score  : 37 points
       Date   : 2022-06-02 19:39 UTC (2 days ago)
        
 (HTM) web link (www.schveiguy.com)
 (TXT) w3m dump (www.schveiguy.com)
        
       | giancarlostoro wrote:
       | I am still unclear on what mustUse is or does is there any sample
       | code?
        
         | simcop2387 wrote:
         | If you want to look at it from an academic perspective it tells
         | the compiler that it should be a relevant[1] type. The idea is
         | that you can make the compiler force the use of the value at
         | least once. This is great for error or result types so that you
         | can require the caller of your code actually check for an error
         | or valid result, this way you can't forget to do it (if you do
         | it's a compile error and you never get to run the code).
         | 
         | [1]
         | https://en.wikipedia.org/wiki/Substructural_type_system#Diff...
        
         | mhh__ wrote:
         | @mustUse is a user defined attribute the compiler recognizes
         | that forces return values it affects to be used.
         | 
         | e.g. if you return something that could contain an error then
         | ignoring the return value could be disastrous.
        
           | loeg wrote:
           | A similar concept is used widely in glibc under the name
           | "__wur" (shorthand for __attribute__((warn_unused_result))).
           | 
           | https://github.com/bminor/glibc/search?q=__wur&type=
        
             | Georgelemental wrote:
             | Rust also has something similar, in the form of the
             | `#[must_use]` attribute.
        
               | loeg wrote:
               | Yeah, and one called `[[nodiscard]]` in C++17 as well.
        
         | Aisen8010 wrote:
         | The official documentation[0] is cryptic as well.
         | 
         | [0] https://dlang.org/library/core/attribute/mustuse.html
        
           | Simon_O_Rourke wrote:
           | I've always wondered if the Dlang docs are intentionally kept
           | vague and cryptic.
        
             | cinntaile wrote:
             | Probably not. The ones creating the docs probably have a
             | deep understanding of the language and can no longer see
             | what information people need to understand the issue at
             | hand.
        
             | arunc wrote:
             | It is definitely unintentional. It's called the curse of
             | knowledge.
        
           | mhh__ wrote:
           | Cryptic in what way?
           | 
           | I can fix it but the example given is clear, no?
        
             | TingPing wrote:
             | I think the example is very clear.
        
           | schveiguy wrote:
           | Oof, seems I got the camelcase wrong. It's `@mustuse`
           | 
           | Working on updating that.
           | 
           | I think the reason the documentation is cryptic is because
           | it's a library-supplied User Data Attribute that is specially
           | recognized by the compiler. The documentation generator is
           | having trouble with it. In code it's pretty simple:
           | 
           | https://github.com/dlang/druntime/blob/705fb36e5fc4d930eed85.
           | ..
        
           | loeg wrote:
           | Seems pretty similar to nodiscard in C++17 and previously,
           | GCC attribute warn_unused_result.
           | 
           | https://en.cppreference.com/w/cpp/language/attributes/nodisc.
           | ..
           | 
           | https://gcc.gnu.org/onlinedocs/gcc/Common-Function-
           | Attribute...
        
       | twic wrote:
       | > However, a nothrow function is still allowed to throw an Error.
       | How does that work?
       | 
       | > How it works is that the compiler still omits exception cleanup
       | code, and the code that catches the Error is not allowed to
       | continue the program. If it does, the program may obviously be in
       | an invalid state.
       | 
       | Yikes? What's the rationale for allowing errors to be thrown out
       | of nothrow functions, rather than just aborting there and then?
        
         | schveiguy wrote:
         | The rationale is that in a correctly written program, an Error
         | should never be thrown. It's similar to UB in C. The compiler
         | can assume Errors are never thrown, and so it can not worry
         | about cleanup in nothrow functions.
         | 
         | But the nice thing is, it reuses the same handling mechanisms
         | as exceptions. You don't have to create something different for
         | handling Errors. In fact, the code that prints error stack
         | traces and exits is the same code that handles exceptions.
         | 
         | Consequently, this is why you shouldn't catch them, or at least
         | not catch them and continue. The exceptions are unittests and
         | contract asserts, where the compiler does guarantee proper
         | stack unwinding.
        
       ___________________________________________________________________
       (page generated 2022-06-04 23:02 UTC)