Semantics of how to `:error` tuples should be treated as job failures about oban HOT 2 CLOSED

This is an interesting idea. There are a few challenges in this approach, namely returning correct exception and stacktrace information.

We could have some code to manually raise/throw inside our job module, but it feels like something that Oban could handle by itself (I don't know how other elixir libraries deal with it).

According to my preliminary investigations other libraries handle this in a variety of ways. Some require returning an explicit :ok or the job is considered a failure, others require you to commit a transaction, and some others require explicit retries.

I intentionally avoided requiring an :ok return value, but the idea of checking for an error tuple has promise.

If perform/1 returns {:error, error}, I think safe_call should return {:failure, job, :error, error, __STACKTRACE__} and the job will be treated as failed, and the scenario where exceptions were raised should use :exception instead of :error for the kind prop (this makes easier for the event listeners to know it's an actual exception or some other data structure that represents the error).

Differentiating between an "error" and an "exception" could be very useful in debugging. However, there are some technical difficulties to consider:

1. The kind value is used by Exception.blame/3 and friends to format the exception and the stacktrace. The kind is :error to denote what we're calling an exception here, so that may require some refactoring to work around.
2. The __STACKTRACE__ macro is only available inside of a rescue or catch block. The best we can do outside of the block is Process.info/2, which isn't always accurate.
3. What is the datatype for error in this situation? Is it an atom, a binary, an exception struct? Calling Exception.normalize/3 or blame/3 on a binary or atom will result in an %ErlangError wrapping it, which may obfuscate the initial error message entirely.

I'll think about this a little more and see if I can work out a suitable implementation. 👍

from oban.

Closing in favor of the PR, #20

from oban.