# Difference between Workflow.wrap() and ApplicationFailure.newFailure()
**URL:** https://community.temporal.io/t/difference-between-workflow-wrap-and-applicationfailure-newfailure/1677
**Category:** Community Support
**Tags:** java-sdk
**Created:** [March 9, 2021, 8:20pm UTC](https://community.temporal.io/t/difference-between-workflow-wrap-and-applicationfailure-newfailure/1677 "2021-03-09T20:20:01Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@Lorenzo\_Di\_Giacomo](https://community.temporal.io/u/Lorenzo_Di_Giacomo)
#### Post date: [March 9, 2021, 8:20pm UTC](https://community.temporal.io/t/difference-between-workflow-wrap-and-applicationfailure-newfailure/1677/1 "2021-03-09T20:20:01Z")
Hello, i was wondering, in a Activity which is the difference on doing Workflow.wrap(Exception e) and add to the RetryOptions associated to that activity “.setDoNotRetry(FullExceptionName)”
VS
calling, always from the Activity, the methods:
throw ApplicationFailure.newNonRetryableFailure(message, exceptionName)
OR
throw ApplicationFailure.newFailure(message, exceptionName)
Thanks
---
### Author:  [@maxim](https://community.temporal.io/u/maxim)
#### Post date: [March 9, 2021, 8:35pm UTC](https://community.temporal.io/t/difference-between-workflow-wrap-and-applicationfailure-newfailure/1677/2 "2021-03-09T20:35:32Z")
When any exception that doesn’t extend `TemporalException` or `TemporalFailure` is thrown from an activity body it is converted to an `ApplicationFailure` before returning it to a workflow. The full name of an exception class becomes `ApplicationFailure.Type`.
The only reason to use `Activity.wrap` (or `Workflow.wrap` in the workflow code) is to allow rethrowing _checked_ exceptions as unchecked. The framework will ignore the wrapper exception and convert the original checked exception to the `ApplicationFailure`.
You can create an `ApplicationFailure` directly instead of relying on the framework default conversion. There are two main reasons to do this:
1. `ApplicationFailure.newFailure` and `ApplicationFailure.newNonRetryableFailure` methods accept _details_ field. The details field can contain any object that can be serialized/deserialized by a configured DataConverter. The details are available in the workflow through `ApplicationFailure.getDetails`.
2. Use `ApplicationFailure.newNonRetryableFailure` to create a failure that is non retryable even if its type is not included into `RetryOptions.DoNotRetry` list.
Note that calls to activities always throw ActivityFailure with an exception that caused the failure as a cause. So a NullPointerException thrown from an activity is going to be delivered to the workflow (after exhausting all retries according to the retry options) as an `ActivityFailure` that has an `ApplicationFailure` with a type equal to `java.lang.NullPointerException" as a cause.