Re: Best practices to handle corrupted records

Either[FailureResult[T], Either[SuccessWithWarnings[T], SuccessResult[T]]] maybe ? On Thu, Oct 15, 2015 at 5:31 PM, Antonio Murgia < antonio.murg...@studio.unibo.it> wrote: > 'Either' does not cover the case where the outcome was successful but > generated warnings. I already looked into it and

Re: Best practices to handle corrupted records

+1 Erwan.. May be a trivial solution like this - class Result (msg: String, record: Record) class Success (msgSuccess: String, val msg: String, val record: Record) extends Result(msg, record) class Failure (msgFailure: String, val msg: String, val record: Record) extends Result (msg, record)

Re: Best practices to handle corrupted records

Unfortunately Either doesn’t accept 3 type parameters but only 2 so Either solution is not viable. My solution is pretty similar to Ravindra one. This “post” was to find out if there was a common and established solution to this problem, in the spark “world”. On Oct 16, 2015, at 11:05 AM,

Re: Best practices to handle corrupted records

I came to a similar solution to a similar problem. I deal with a lot of CSV files from many different sources and they are often malformed. HOwever, I just have success/failure. Maybe you should make SuccessWithWarnings a subclass of success, or getting rid of it altogether making the warnings

Re: Best practices to handle corrupted records

'Either' does not cover the case where the outcome was successful but generated warnings. I already looked into it and also at 'Try' from which I got inspired. Thanks for pointing it out anyway! #A.M. Il giorno 15 ott 2015, alle ore 16:19, Erwan ALLAIN

Re: Best practices to handle corrupted records

What about http://www.scala-lang.org/api/2.9.3/scala/Either.html ? On Thu, Oct 15, 2015 at 2:57 PM, Roberto Congiu wrote: > I came to a similar solution to a similar problem. I deal with a lot of > CSV files from many different sources and they are often malformed. >