Hey boris,

thanks for creating this ticket, looking into it now.

Best,
Tobias

Hey boris,

I can reproduce this and can track down the change that introduced this.
We'll keep you in the loop on how we will progress here.

One detail here: can you confirm that this only occurs with Process Definitions that have multiple start events?

Thanks again so far.

Best,
Tobias

Hi,

Great that you can reproduce! I can't confirm in the sense that I can't be sure, but my tests seem to show that.

As a sidenote, for many, many releases Camunda has been throwing `NullValueException` when I call `getFormService().getStartFormVariables(processDefinitionId)` for the same kind of definitions - ones with multiple signal start events. Not sure if it's related (or even if that's not "normal") - I just wanted to mention it.

Regards,
Boris

P.S. I think `getStartFormData` also throws the same `NullValueException`.

Hi boris,

thanks for that input. Regarding "confirmation", I rather meant if you are only experiencing this for multi-start event processes or also for the ones with single start events.
That would be enough confirmation for my findings.

One note for start form variables/data/key in general. You can only get those for single start event process models. It just doesn't make sense otherwise.
Therefore, we are throwing the NullValueException for the "getStartFormVariables" method in that case. This is actually expected because calling this method on a multi-start event model does not make sense.
This is also what we would probably do for the "getFormKey" method here to make it consistent and not run into an NPE that is considered as a rather "uncontrolled" exception.

I am not sure about your use case here for calling those methods on all process definitions, no matter how many start events there are.
Maybe you can explain that a bit more. But we will most probably not make the exception disappear here but rather make it more explicit and controlled.

Hope that is a reasonable answer for you here.

Best,
Tobias

Hi,

Yes, I only experience this for multi-start event processes.

As for the other exception - yes, I agree it doesn't make sense to get start-form-anything for a process with multiple start events - my point was just that an exception was thrown instead of, for example, returning `null` (as was the case with `getStartFormKey`). Making the methods consistent would be the best solution.

My use case is not that special - I just have the same code path for all definitions - and I handled the `null`/`NullValueException` cases.

A couple of questions:

1) I'm using the community version of Camunda which means that I'll get the fix in 7.18.0, is that correct?

2) Is there a "proper" way to workaround that issue? If I try-catch the NPE, my code works, but Camunda logs the exception. I seem to be able to suppress that log by using `setEnableCmdExceptionLogging(false)`, however the documentation suggests that's not a very good idea (which I agree with). Any other ideas?

Regards,
Boris

Hi boris,

thanks for those insights, that's very helpful to understand what you're doing.
In my regard, it's actually better if an API throws a "controlled" and meaningful exception in such a case instead of just returning "null" which is - if you ask me - used way too often in Java out of convenience.
The "null" return value might actually mean different things which is why I think an API should avoid returning this as much as possible.

Regarding your use case:
Maybe you could rather go for a more "proactive" way of figuring out if you should actually call the start form methods for a process or not.
More specifically, this would mean checking if there is only a single start event or not.
There are multiple ways of doing this, depending on which objects you already have in your code for example.
The process definition entity that you receive when you use the ProcessDefinitionQuery API has a "getInitial" method that is only non-null for single start event definitions, as far as I know.

Hope that helps in moving forward with this.

Best,
Tobias