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

Hi,

I absolutely agree that exceptions are mostly better than returning `null` - especially in this case!

Thanks for the ideas, I'll perhaps try to do as you suggest.

And thank you very much for the great support!

Regards,
Boris

Thanks for the constructive discussion, boris.
Happy to help, let us know if there are any further questions regarding this in the future.

Best,
Tobias

Just to follow up on this issue - the same problem still happens on 7.18.0.

Hi boris,

this is still in our backlog.

Due to other priorities, we didn't work on this yet. We also did not schedule this yet for any specific version.
If you would like to speed up the process of fixing this, we are happy to receive a contribution to our GitHub repository.

Best,
Tobias

Hi, yes, no worries, I just wanted to mention it for completeness' sake. It's not an urgent issue so no problem!

This ticket was migrated to github: https://github.com/camunda/camunda-bpm-platform/issues/2654. Please use this link for any future references and continue any discussion there.