imho
tsk tsk
Try/catch is not a validation logic.
We should validate before the persistence and sometimes we should validate it again if the thing goes south (for example, a duplicate primary key or such like that). However, it is not always possible but we could do the best before we call the persistence layer.
Also, i’m not fond to create so many Exception classes, we used in one project and finally we created a new Exception for every type of error, no matter if the Exception class was already defined or not, because we have so many Exception classes that we miss the track of all of them.
User generate exceptions breaks the flow of execution and they shouldn’t be used unless they are an unexcepected exception, not an expected error (such a a wrong address, that’s not an technical error but an user input error).
This could could be written as:
try:
if order.validate()==false
return "order is not valid"if AddressVerificationClient(order.contact).validate()==false)
return "address is not valid"clientAccount=PaymentClient(user.info)
if clientAccount=false
return "unable to obtain the client";order=charge(clienteAccount,order.amount)
if order==false)
return "unable to charge"return "ok" // or maybe returns the order
catch Exception e:
// We don't know or care, maybe the database is down or the table was deleted or.... (we have around +100 types of errors here but it failed and we don't want to continue). return null
i.e. exceptions are not a “second return value”.