Neither cipher suite is good. Which one is the least bad depends on your threat model.

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA has two problems:

• It uses SHA-1 to authenticate the server's signature. SHA-1 is broken for some uses: its collision resistance is broken, but not its first or second preimage resistances. An attack on collision resistance breaks certificate signature, but I don't think it leads to a practical exploit for handshake signatures, where the attacker doesn't get to choose all the data. So this is an intrinsic, but theoretical weakness.
• It uses CBC, so it is potentially vulnerable to a padding oracle attack: Lucky Thirteen and its variants. The original attack relied on an error message which was required in TLS 1.0 but is forbidden in TLS 1.2, so a functionally correct TLS 1.2 implementation is not vulnerable to the original attack, but it is still be vulnerable to timing-based variants unless implementated very very carefully. OpenSSL and some other major implementations of TLS are fully protected against these attacks, but less reputable implementations are not. Furthermore the protection comes at a performance cost which is paid for every packet exchanged during the connection. The attack requires somewhat precise timing which is realistic for an adversary who can run code on the same machine (as either the client or the server), possibly realistic for an attacker on a local network, but not realistic when there are multiple routers between the attacker and both parties.

TLS_RSA_WITH_AES_256_GCM_SHA384 has two problems:

• It relies on RSA PKCS#1v1.5 decryption, so it is potentially vulnerable to a padding oracle attack: Bleichenbacher's attack and similar attacks (in particular Manger's attack) and variants. There has been a long history of Bleichenbacher and Manger attacks on TLS, although after CAT, when ROBOT came out OpenSSL and several other major implementations were fully protected. Protection requires very carefully written code, but does not incur a performance penalty (beyond what is required to protect RSA private key operations in general against side channels). The attack is purely on the server side, the client implementation is irrelevant.
• It relies on RSA decryption and does not use a Diffie-Hellman key exchange, so it does not have forward secrecy. Forward secrecy was not an objective of the original design of TLS, but it is achieved by all modern cipher suites that use (EC)DHE. Forward secrecy means that if an attacker manages to record encrypted connections (easy) and to obtain the server's private key (difficult), the attacker will be able to decrypt past encrypted connections (in addition to, obviously, being able to hijack all future connections). This attack is intrinsic to the protocol design and cannot be mitigated by an implementation: the only solution is to use a good cipher suite. However, it is not relevant to all threat models, and involves a very powerful attacker — much more powerful than a mere man-in-the-middle.

If you can use both TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA and TLS_RSA_WITH_AES_256_GCM_SHA384, then you have all the cryptographic primitives needed by TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and you should use that. (The AES_128 and GCM_SHA256 variants are also fine: the added security from having more bits there is purely theoretical.)

If you are in the very weird situation that only TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA and TLS_RSA_WITH_AES_256_GCM_SHA384 are available, then it comes down to which attacks concern you and how good client and server implementations are. You have to choose between a potential Lucky Thirteen vulnerability (on either the client or the server), and a potential Bleichenbacher vulnerability (on the server) plus the lack of forward secrecy.

I agree with @schroeder, I don't think you can do a direct "which is better?" comparison with cipher suites.

That said, Mozilla's TLS Recommendations currently lists DHE-RSA-AES256-GCM-SHA384 in the INTERMEDIATE list (although right at the bottom), and lists ECDHE-RSA-AES256-SHA in OLD.

So maybe that's your answer? ... neither are great, but at least according to Mozilla, DHE-RSA-AES256-GCM-SHA384 is better.

On the cmd line, try:

$ openssl ciphers | tr ':' '\n' 

This would give you the list of ciphers in the decreasing order of "strength". This list should help you evaluate the two ciphers in your question.

Risks of CBC ciphers

To attack an implementation vulnerable to variants of POODLE and Lucky13, one of the sides needs to be vulnerable (not a given, e.g. if SChannel is used on both sides it should be secure) and the attack is active, detectable in traffic analysis.

Risks of RSA keyex ciphers

To attack a recording of a connection made using a non-PFS cipher suite, the attacker needs to get access to the private key corresponding to the end-entity (leaf) certificate, potentially years after the certificate has expired and the disk that contained it has been disposed of. This is a safe passive attack (depending on how you get the private key).

Summary

Because of this, I think RSA key exchange is worse than CBC cipher suite. But really, you should avoid both - you should allow in TLS1.2 only what is allowed in TLS1.3.