Jorge Castro
1 min readMar 9, 2019

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”.

Sign up to discover human stories that deepen your understanding of the world.

Free

Distraction-free reading. No ads.

Organize your knowledge with lists and highlights.

Tell your story. Find your audience.

Membership

Read member-only stories

Support writers you read most

Earn money for your writing

Listen to audio narrations

Read offline with the Medium app

No responses yet

Write a response