философия на пустом месте

Недавно тут тест на гендерную ориентацию проходили; одна из задач - тебе дали полтинник, ты предлагаешь какую-то сумму партнёру, если тот отказывается, вы ни хрена не получаете, если соглашается, то ты получаешь остаток, а он предложенную долю. Наука говорит надо предлагать двадцатку; говорят, французы обижаются, если меньше пятнахи им дают, а немцы и на пятёру согласны. Ну типа тоже деньги. Мы с подругой ответили одинаково (пополам).

Интересно другое. Ну хрен ли там полтинник. Ради полтинника ещё собачиться. А вот если существенная сумма. Скажем, 500 тысяч. Вот тебе предлагают сто тысяч, ты что, откажешься? Вряд ли. Так что 500к можно как бы делить на 400-100. На самом деле пропорция зависит от того, сколько тебе денег надо. Может быть, кому-то и десятка баксов пригодится.

Но идём дальше. Вот поделили мы 400-100. Теперь мне в руки попадает, скажем, 50К. Ну так для владельца 400К... ему как-то неудобно штуку предлагать, что ему штука. В результате перекос в первом туре приводит к тому, что захапавший бОльшую сумму получает бОльшие доли в следующих заходах. Если, конечно, вы с ним играете. Но ведь 30к тоже на дороге не валяются. Обычно.

Я это к чему. К тому, что психологически получается, что богатому деньги легче достаются, просто на основе социальных ожиданий. Ну кто бедному предложит из 500к сотню. Ему можно и 20к предложить; он и разницы не чует между 20 и 200.

Вот такой горький катаклизм.

the things we fight every day in Java

I've discovered that I spend tons of time doing the following:

* a component either throws an exception or returns an enum;
* I have a "switch/case"-like sequence of statements reacting to exception and wrapping them into a "result-type enum";
* or, I map the returned enum to another, using some kind of heuristics;
* in the meantime, I kind of lose "specific error data" - image size, error message - since it is mapped to an enum

And I feel like I am not aware of a neat solution for consuming "innocent" exceptions (example: "your image is too big") into "result types".

Maybe I should not; maybe it is better to wrap an exception, and pass it along. Or maybe it makes sense to replace enums with implementations of an interface, rich enough to help make decisions regarding what to do about specific failures.

I wonder if someone can give me an advice as simple as my problem is. So that, given that the solution is simple and clear, we could fix our code, lots of code. Seems like the complexity of the majority of our application code is caused by this mix of exceptions, error codes, status enums, and switch/case statements base on those enums.

Here's a typical example:

class ImageUtil {...

public static ImageStatus verifyImage(byte[] image) {
  try {
    new ImageVerifier().verify(image);
    return ImageStatus.OK;
  } catch (ImageTooBigException itbe) {
    return ImageStatus.TOO_BIG;
  } catch (BadImageRatioException bire) {
    return ImageStatus.BAD_RATIO ; // dropping all details
  } catch (InvalidImageTypeException iite) {
    return ImageStatus.INVALID_TYPE; // dropping all details
  } catch (ImageVerificationException ive) {
    return ImageStatus.JUST_BAD; // could not figure out what was wrong - check ive.getMessage();
  }
}
....

class FileUploader {...

public /*static*/ FileUploadStatus uploadFile(HttpRequest rq,...) {
  if (!rq.hasParameter("myfile")) {
    return FileUploadStatus.NO_FILE;
  }
  try {
    byte[] data = rq.getFileData("myfile");
    if (data == null) {
      return FileUploadStatus.HAVE_FILE_GOT_NO_DATA;
    }
    // this is kind of nifty part, shortcutting using EnumMap
    return FileUploadStatus.forImageStatus(ImageUtil.verifyImage(data));
  } catch (IOException ioe) {
    return FileUploadStatus.IOEXCEPTION;
  }

And so on.

Any good solutions, anybody?

more philosophy from dailywtf

European Air War was doomed. It was four years in development and not even close to being ready to ship. In Brand's first month at MicroProse, the whole programming team on European Air War quit, sensing that their project was on the verge of cancellation. Not only that, but everyone had grown tired enduring the stress of the weekly "why-shouldn't-we-cancel-this-project" meetings with the executives. In these meetings, they'd have to choose their words carefully when answering the executives' tough questions about the budget as well as major bugs in the system such as...

Theory and Applications of Categories

Theory and Applications of Categories - absolutely free