# RetryOptions.DoNotRetry vs ApplicationFailure.newNonRetryableFailure
**URL:** https://community.temporal.io/t/retryoptions-donotretry-vs-applicationfailure-newnonretryablefailure/12438
**Category:** Community Support
**Tags:** java-sdk
**Created:** [June 10, 2024, 9:55am UTC](https://community.temporal.io/t/retryoptions-donotretry-vs-applicationfailure-newnonretryablefailure/12438 "2024-06-10T09:55:56Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@jxwang](https://community.temporal.io/u/jxwang)
#### Post date: [June 10, 2024, 9:55am UTC](https://community.temporal.io/t/retryoptions-donotretry-vs-applicationfailure-newnonretryablefailure/12438/1 "2024-06-10T09:55:56Z")
Hi Temporal Team,
We want to simplify and standardize our codes.
RetryOptions.DoNotRetry and ApplicationFailure.newNonRetryableFailure
Both will be able to throw non-retryable failure.
But is there any reason we need to use DoNotRetry, as ApplicationFailure.newNonRetryableFailure already provided a standard way of handling non-retryable failure, while in DoNotRetry we need to maintain a separate config for exception list.
So we can have a errorcode constant together with ApplicationFailure.newNonRetryableFailure and don’t use RetryOptions.DoNotRetry at all?
---
### Author:  [@maxim](https://community.temporal.io/u/maxim)
#### Post date: [June 10, 2024, 4:55pm UTC](https://community.temporal.io/t/retryoptions-donotretry-vs-applicationfailure-newnonretryablefailure/12438/2 "2024-06-10T16:55:23Z")
In the case when an activity owns a definition of what’s retryable and what’s not, the `ApplicationFailure.newNonRetryableFailure` is the way to go. In the cases when an activity implementation is not owned by the workflow writer or is shared by many workflows, using `RetryOptions.DoNotRetry` is needed.