Aha, I may have misunderstood your text initially then. You problem is with returning null for Session#get where you would rather have it throw an exception. We usually do use find methods to possibly return null and get methods to throw if nothing can be found in our APIs, so Session#get returning null indeed seems like an odd one. Do I understand it right, that you'd ideally want that method to throw an exception now? IMO that would be fine for me. People have an alternative, which is Session#find, though we would have to add some find overloads:

	<T> T find(Class<T> entityType, Object id, LockOptions lockOptions);
	Object find(String entityName, Object id);
	Object find(String entityName, Object id, LockMode lockMode);
	Object find(String entityName, Object id, LockOptions lockOptions);

Is absurdly verbose.

I'd rather say a bit more verbose. But then the added verbosity has a point: being explicit about an exceptional case.

 try {
- Book book = session.get(Book.class, id);
+ Book book = session.getOptional(Book.class, id).orElseThrow(() -> new EntityNotFoundException("message", id)); 
 book.blahBlahBlah();
 // .... lots of stuff
 }
 catch (EntityNotFoundException e) {
 // this catch might even be a couple of frames up the stack!
 reportToUser();
 }

Also note that catching EntityNotFoundException a couple frames up the stack, depending on context, can be dangerous: you don't have any guarantee that the entity which was not found was the book, it could have been another entity that we also did not find... So yes, it's a bit safer than catching NPE, but still not the panacea. With orElseThrow, at least, you can use a custom exception type.

I would rather just write if (book == null).

But your assumption is that the handling code might be several frames up the stack, so that won't work. You need an exception with that assumption... If you remove that assumption, of course book == null has an equivalent with Optional: just call book.isAbsent().

the problem I'm worried about here, which is that users are too lazy or distracted to write code that doesn't NPE.

I'd argue that just throwing another, more specific unchecked exception will help with debugging, but won't prevent the same problem from happening again, just with a different exception. Optional would, because even lazy users would have to go out of their way to handle the "absent" case.

IMO we can try to encourage more concise code, or safer code, but hardly both. At best we can limit the added verbosity resulting from the added safety, but it won't be zero.

Pattern matching might help one day, but even that won't address your "couple frames up the stack" requirement and will still add verbosity.

Also note that catching EntityNotFoundException a couple frames up the stack, depending on context, can be dangerous: you don't have any guarantee that the entity which was not found was the book, it could have been another entity that we also did not find.

Actually I think it's quite safe most of the time. I don't usually call get() lots of times with lots of different ids in one transaction. I usually do it for at most one or two ids, and then navigate from there. Even if I do call it for a whole batch of ids, it's almost certain that in that case every id in the batch has the exact same semantics, and can be reported uniformly.

Note that the exception type we would use here would very clearly distinguish a "not found" coming from get() from any other sort of "not found" (e.g. one coming from deeper in Hibernate).

Sure, sure, of course you can come up with situations where what I've just said isn't true, but I'm most focussed on the very common cases.

But much more importantly, I'm worried about what happens when things aren't right, when the user doesn't write correct code: how does this error get reported in the log or stack trace?

• Does it get reported as NullPointerException or NoSuchElementException with no information about the primary key or entity?
• Or does it get reported as EntityNotFoundException with the entity name and the primary key?

And sorry, but I just don't think I can rely on the user to always write

session.getOptional(Book.class, id).orElseThrow(() -> new EntityNotFoundException("message", id));

Because I have met users. They don't do that.

Do I understand it right, that you'd ideally want that method [get()] to throw an exception now?

Yes, that would be completely perfect, but also massively breaking. I don't see it as an option, sadly.

That's why I'm proposing to use load() for this: we've already promised to break it (since 6.0). And it already has the exact signature we need, and a name which is reasonable.

But your assumption is that the handling code might be several frames up the stack, so that won't work.

Actually I think it's quite safe most of the time. I don't usually call get() lots of times with lots of different ids

Granted, @yrodiere, I usually prefer to write extremely tiny methods, with a very low level of nesting, and I'm a compulsive user of Extract Method, so my "two or three frames up the stack" is actually not so very far away from the source of the exception.