[m-users.] [m-dev.] Pure Functional throwing exception

[Julien Fischer]

Hi Charles,

On Wed, 8 May 2019, Charles Shuller wrote:

> In the below message you mentioned it would be better NOT to do:
> 
> exception.throw("Badness happened, terminating")
> 
> Which is something I do quite a lot of to get a non-local exit.   As
> in, the exception should never be handled, I just want the program to
> halt with some appropriate error message.

That depends on what your definition of "appropriate" is.  Leaving
things up to the uncaught exception handler means that:

    1. you will potentially get a stack trace printed.
    2. you will have no control over the formatting of the error message.

For most of the users I deal with, neither of those things would be
appropriate, so programs typically have an exception handler at the
top-level handling the exception types used by the standard library (at
least).

> It sounded like you recommended the following instead (note the addition of the exception.software_error):
> 
> exception.throw(  exception.software_error("Badness happened, terminating")  )

There's (usually) no reason to module qualify throw and software_error.
(Indeed you could just call require.error/1, which does the same thing.)

> Which is a bit more typing, but I don't see how this makes things any
> better. 
> A new type for each kind of exception makes sense to me if I
> wanted to handle my exceptions, but boxing all messages as
> software_error types doesn't intuitively make sense to me.
> 
> Can you explain your reasoning for me??

For me (at least), most non-trival programs *do* end up catching
exceptions and it is useful for to be able to distiguish betweeen the
different kinds of errors that they represent.  This is more difficult
when the exceptions are just strings.

Julien.