Error handling in validators

[hin3x]

We are using velocity expressions to validate the contents of our DS fields. I encountered the case where a 'Nullpointer' is raised from within the velocity expression evaluation. This NullPointer is trapped in our overloaded IDACall servlet where we add the exception into the DSResponse.

This approach causes the UI to display a corrupt error message since a boolean response in expected (FormItem.validate).

Similar to my previous thread, I have the requirement to display our custom error box with the error information.

I am looking for a way to display the error information we send over correctly. As far as I can tell this is only possible if I can overload the FormItem.validate method in some way. I tried to do this by defining the same method on on of our editors which extend the FormItem (trough TextItem) but this seemed to have no effect at all (probably due to native JS functionality).
Do you see a way to override the functionality in that validate method?
I noticed in the debug console that this information is available under the 'clientContext' property in the DSRequest but I can't find a way to access this information.

Alternatively, in case the previous approach is not possible at all, I could manage to create a DS Response which adheres to the expected format, since I got all the information. I tried a few ways to mock the response of a validation call, but the UI never seemed to interpret it correctly (no error was raised, but no validation error was displayed either). Is there some utility or pattern I can use to create a good validation response from scratch and where I can send back a text string which contains the validation error message (in this case the exception details).

Thanks for you insight!

UPDATE:
I did some further investigation and came to the conclusion that I can build a proper validation result if I would be able to access the ValidationContext in our overloaded IDACall servlet (to get the information about which field was validated last and therefore caused the error).
I noticed that this information is available in the 'clientContext' property in the DSRequest when I look in the developer console output, but I can't find a way to access this information.

[Isomorphic]

Validators should not crash. Avoid the error conditions within the validators and return the error message as a normal error.

[hin3x]

I agree that they should not crash, but our end-users are able to configure velocity expressions on any DS field we have on screen.

There will be cases where they configure something that is not correct and will raise errors when executed. This means that we have to give and indication to the end-user to tell him at least that something failed.
At best this would be in our customized help box, worst case as the error message displayed in the validation error tool tip.

I did not manage to come close to implementing the first way due to the 'FormItem.validate' limitation (expects boolean result).

I came very close to implementing the second approach, all I need to complete it is access to the field which was validated last. This is an extract from our code in the overloaded IDACall servlet (catch block wrapped around the DSRequest.execute call).

if(dsRequest.getOperationType().equals("validate")){
				
  ErrorReport rep = new ErrorReport();				
  rep.put("recordPath", "/" + dsRequest.getDataSourceName());
			    
  // TODO Add refrence to actual field here 
  rep.addError("reference", new ErrorMessage(e.getMessage()));
			    				
  DSResponse resp = new DSResponse(dsRequest.getDataSource());
  resp.setStatus(DSResponse.STATUS_VALIDATION_ERROR);
				
  resp.setErrorReport(rep);
  resp.setDropExtraFields(false);
  resp.setData(new Boolean(false));
				
  return resp;
}

I see two possible ways to achieve this: expose the data contained in the clientContext property/field of the request or by providing access to the ValidationContex (which contains a reference to the last validated field) - by hooking it up in the DSRequest when created.

I am not sure what you mean with 'return the error message as a normal error'. Our regular approach here is what I was using before, which is returning the exception to the caller as DSResponse payload, which triggers the display of our custom error box on the client.

Thanks!

[Isomorphic]

What do you mean by "end users"?

End users in the normal sense definitely should not have direct access to define a Velocity expression. It allows them to call any Java method in the system, which implies they would need to have all the server-side documentation and understand how to do error handling, understand transactional implications, etc. You should provide a more constrained means of defining validation rules instead (eg use a FilterBuilder).