Handling errors from Stan

[Daniel Lee]

Bob brings up a good point. Exceptions aren't part of the Stan language.

This conversation came up with a pull request that documented the C++ code for throwing std::out_of_range exceptions. In the past, we had only used std::domain_error.

From the language, in a sense, this isn't really like throwing an exception. It's an unrecoverable error at runtime. Here's a silly example:

parameters {

  real alpha[1];

}

model {

  alpha[2] ~ normal(0, 1);

}

Currently, this will show that the 100 tries for initialization failed. This is clearly a user error and no matter how many iterations of any algorithm that gets called will fix this.

Although it might seem like it gets tricker, I think this example should still stop as soon as the C++ throws a std::out_of_range exception:

parameters {

  real alpha[1];

  real<lower = 0, upper = 1> beta;

}

model {

  if (beta > 0.7)

    alpha[2] ~ normal(0, 1);

  else

    alpha[1] ~ normal(0, 1);

}

This will continue to sample and in this case, does the right thing for alpha and beta. (if the right thing is for beta to be uniform 0 to 0.7.) 

The generated C++ and the log probability function faithfully codes this. I think it's the algorithm around it that should stop because there's something wrong with the evaluation of the log probability for those values and it's not just that the log probability evaluates to -inf at that point.

I'm not sure we need to have more fine-grained errors in the language except perhaps adding an exit() type of function. reject() will indicate some problem with that particular set of values and exit() should be reserved for when there's a problem so bad that you need to stop and think about what you're doing. Right now, we don't have anything in the language that will terminate the algorithm (any/all algorithm).

Daniel

On Sun, Aug 21, 2016 at 8:33 AM, Bob Carpenter <notifi...@github.com> wrote:

But how will users know what throws out_of_range exceptions?
I wouldn't even know without looking at the source.

Exceptions per se aren't really part of the language from the
interface perspective, though they are if you look at the C++ level.

I'm not even sure what kind of exception our reject() statement
throws, but if we start distinguishing behavior, then we want to
specify that and probably allow rejection to be more fine-grained
to allow users to write proper function error handling.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub, or mute the thread.

[Bob Carpenter]

I like the reject() vs. exit() distinction from the language.
Can you create an issue in the language? That one will be
easy as soon as there's an exception I can throw to exit.

This is something we should take up at the meeting, so I
added a bullet point.

- Bob

> --
> You received this message because you are subscribed to the Google Groups "stan development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to stan-dev+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.