fix: Throw NonTransientAiException on syntax errors in prompt templates

[pkubowicz]

IAE/ISE are too generic, it's hard to use libraries that throw them.

Using NonTransientAiException clearly marks the exception as coming from Spring AI, plus will integrate nicely with code that already avoids re-sending requests when faced with this exception.

[sunyuhan1998]

To some extent, I agree with this PR, but I have some concerns. I wonder if there are already users relying on IAE/ISE to determine rendering failures, and by changing the exception type, their existing logic might no longer work.

[markpollack]

Hi. I actually thought about the design of the library in this regard a good amount when starting the project. In previous projects such as Spring XD and Spring Cloud Data Flow there was an 'library' exception ,eg. XDException or similar. This would wrap things like IAE and so on. This turned out to be an antipattern. The exception thrown meant nothing - basically no useful info until you looked at the inner exception and then at the inner exception text and it's stack trace.

Looking around at other Spring librarires, IAE etc is thrown directly. See here or here for example. I believe this is the correct design. Also not NonTransientAiException while it is there in the library, is specifically for the retry functionality so that the retry loop knows when it should retry or not (like spring tx excetpions) and wouldn't be the right choice for such a design had we chosen to use it. I realize you picked it as it seems like an 'innocent' exception and probably didn't want to introduce another one.

[pkubowicz]

You gave examples from code serving totally different purpose.

You gave HibernateUtils. Exception is thrown there when Spring developers did something wrong (are not able to correctly talk to Hibernate code). From the perspective of a developer using spring-data-jpa, this is not a situation they are responsible for, so there is no sense in anticipating this and catching the exception appearing in this situation, so a generic IAE/ASE or even RuntimeException is equally good.

If you search https://docs.spring.io/spring-framework/docs/current/javadoc-api/overview-tree.html for ParseException, you will find lots of custom exceptions, and for a good reason: those are (mostly) exceptions for situations where the 'user' (as opposed to 'Spring developer') did things wrong, like by providing a bad SPEL string and so on.

Prompt and PromptTemplate are directly facing the user, so it's a common situation that users will pass syntactically incorrect prompts (especially if prompts aren't hard-coded).

A good library serves the user by using the features of strongly typed language (exceptions are types) instead of downgrading user to "stringly typed" code (reasoning whose 'fault' it is, user's or library author's, only by looking into exception.message that is not documented and has no guarantee to be stable).

I've been using Spring Framework for more than 15 years and I remember the selling point from the start was that the framework throws different types of exceptions for different situations (like in Spring JdbcTemplate that made sense of generic SQLException).

So I believe it's the Spring way to have a non-generic exception for an exceptional situation that is known to happen again and again, for multiple users.

Go ahead and throw IAE/ISE when something unexpected happens when rendering prompt. But there are situations where you know the user-supplied input string was incorrect, and then, a non-generic exception should be thrown.