What is the impact of deliberately throwing an exception?

In my simulation, I have a process for logging in an OAuth user into our RESTful service. It is littered with conditional code, to mimic the logic that a client application needs to go through. If there is a failure, I do debug logging, so as to be able to trace what happened.

Well, yesterday I got to exercise that code when an upstream service provider was having issues. And the results were not good. The code as written did bad things to Gatling. My suspected culprit was deliberately throwing exceptions.

My code looks like this:

`
.doIf(_.status == KO) {
exec()
.console.valueOf(RESPONSE_BODY) // my custom logging code…
.exec(session =>
throw (new Exception("failed to get INDIVIDUAL_ID for " +
session(USER_NAME).as[String]))
)
}

`

What is the impact of throwing that exception in the middle of the scenario, and should I avoid doing that if I want Gatling to continue running properly? Or in other words, could that be part of the problem? Or is it more likely caused by my multi-threading code getting deadlocked and Gatling running out of threads?

Well, yesterday I got to exercise that code when an upstream service
provider was having issues. And the results were not good. The code as
written did bad things to Gatling.

Which means?

What is the impact of throwing that exception in the middle of the scenario

An Exception will cause a Chainable
<https://github.com/gatling/gatling/blob/master/gatling-core/src/main/scala/io/gatling/core/action/Actions.scala#L55>
Actor
to crash, restart and propagated the Session to the next action in the
chain.

, and should I avoid doing that if I want Gatling to continue running
properly?

It should be fine (but not optimum).

Or in other words, could that be part of the problem? Or is it more
likely caused by my multi-threading code getting deadlocked and Gatling
running out of threads?

What does a thread dump says?

Thanks for the info, that helps me narrow it down!

The behavior I was seeing was Gatling just stopped outputting anything. I didn’t dig too far into it, because prior to that I was seeing all the exceptions that I was throwing, which was telling me that things were going wrong with the system under test. The purpose of my inquiry was to see if the problem was the exceptions, or something else. It sounds like it is something else. Which means I bet it is the multi-threaded code for caching login data. When I wrote it, I did not think through the scenario of what to do if a login attempt fails. Time to implement appropriate logic for that.

It might also mean that some messages/sessions where lost during some actor crash.
There’s a “leak” DataWriter that might help you diagnose where lost sessions were last seen.