Okay, cool. Let's do that, then. Maybe it's cleaner? I don't think it matters functionally, though.
On 28 Apr 2014, at 9:32, Jonathan Shaw <notifications@github.com> wrote:

> In src/banjo/controllers/JobsController.java:
> 
> > +                job.deleteAmberPart(jobFile.getId(), amberSession);
> > +                jobFile.wipe();
> > +                jobFile.delete();
> > +            }
> > +            File[] files = UploadUtils.listFilesFor(job);
> > +            for (File f : files) {
> > +                log.error("adding File {}", f.getName());
> > +                job.newFile(f.getName(), f.length(), new FileInputStream(f));
> > +                jobFiles.add(job.finishFile(f.getName(), new Tika().detect(f)));
> > +            }
> > +        } catch (IOException | NoSuchAlgorithmException e) {
> > +            log.error("Things went wrong... sorry");
> > +            e.printStackTrace();
> > +            response.setStatus(HttpServletResponse.SC_BAD_REQUEST);
> > +            model.addAttribute("exception", e);
> > +            model.addAttribute("stackTrace", e.getStackTrace().toString());
> 
> It is indeed. We could still return inside the catch though. job and jobFiles will be populated but useless in the response
> 
> —
> Reply to this email directly or view it on GitHub.
>