пример:



Концепция Exception горовит, что данная ситуация не разрешима.. как было бы хорошо иметь throw "something like Warning", дабы не придумывать дополнительного объекта для Warning, что нужно заполнить при таком-то и таком-то случае.. 

кто, что думает по этому поводу?   

Это сообщение отредактировал(а) polosatij - 1.10.2008, 23:30

Потом спросишь почему нельзя на throws вешать анотацию @If ?   
Знаешь поговорку про кота которому делать нечего?

Это сообщение отредактировал(а) fixxer - 2.10.2008, 07:14

Я не очень понял идею - хотчется автоматического заполнения сообщения для Exception или что-то еще ?

  

Но на самом деле вопрос скорее всего правильный. Это действительно ограничение известных мне языков, и я не знаю решено ли оно где-либо (в C# есть хитрая конструкция, но она немного для других целей).
Я понимаю проблему так, есть некий метод:
и есть метод, вызывающий его:

При обычной обработке исключений, выполнение по блокам идёт так: A, throw, C, D, т.е. в блок B мы вообще никогда не попадаем. Но иногда было бы полезно иметь такой порядок: A, throw, C, B, D, т.е. после обработки исключения в catch метода main хотелось бы снова вернуться в метод doSomthing и закончить работу. Т.е. хотелось бы иметь концепцию "нефатальных" исключений (по английски их зовут continuable exceptions), позволяющих продолжить работу.

Хотя в некотором роде эта проблема решается блоком finally.

PS: В C# есть такая хитрая команда как yield return, позволяющая вернуть некое значение, а при следующем вызове этого метода продолжить выполнение со середины, но там много ограничений и вообще сделано это было для обработки коллекций, а не запутывания порядка выполнения 

Добавлено @ 11:01
Хотя может я и усложняю, а автор темы мечтает о чём-то совсем простом   

Это сообщение отредактировал(а) Дрон - 2.10.2008, 11:08

сам догадался?   



неа, как мне её знать, если я вкалываю по 16 часов в сутки? 

Дрон, 

в принципе, на мысль можно и посмотреть с того бока, что ты преподал..

я имел ввиду следующее:



например: делаем запрос на сервер, что-то типа "select * from blabla;".
этот запрос возвращает только 100 данных (из, например 102) и кидает Warning => внимание, я прислал тебе только 100 сообщений по регламенту нашего сервера..

или.. если это покажется не очень удачным примером..

пример 2: делаем запрос на сервер, отсылаем какуй-либо запрос на тему add instance;
с сервера приходит warning: "запрос был осуществлён и имеет смысл, но в вашем запросе пустое поле А"..
это значит, запрос так и так имеет смысл, но следует предупреждение с сервера   

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

если же кидать Exception  в этом случае и вылавливать его по типу, то в данном случае идёт нарушение семантики и ведёт к заблужению, например, програмера другого, что копается в том же самом проекте.. можно, конечно, обо всём договориться, но это уже другая история   


Это сообщение отредактировал(а) polosatij - 2.10.2008, 11:38

Концепция Exception говорит, что ситуация не разрешима на данном уровне и проблему надо передать на более высокий уровень.

А вот твоя концепция не понятна. Как и что в этом случае должно происходить?


Дрон, то что ты говорил, реализуется ExceptionHandler-ми. Если реализовывать это на уровне языка возникает куча вопросов как должен выглядеть стек вызова в таком случае, что делать с Exception-ами (кто их должен обрабатывать) и т.д.

С вашего позволения, продолжу телепатить 

Видимо автор хочет возвращать помимо результата функции N ещё и предупреждение X: "ау, функция отработала не так как вы можете ожидать". Я обычно в таких случаях возвращаю объект обёртку, содержащий два поля: результат N, и его статуст X. Это работает, но ведь в своё время исключения и были сделаны для того, чтобы функции не возвращали статус ошибки вперемешку с данными и не требовалось постоянно проверять что-нибудь вроде:
if (GetLastError() != OK) ... Но всё же не понятно, как (и зачем) это красиво встроить в язык.


так в том и дело, что мне кажется, что реализация на уровне языка и соответствующие хитрости в стеке могут быть более эффективны, чем самодельный обработчик. С другой стороны -- всегда можно сделать специфичный обработчик под свои нужды, который лучше будет решать поставленную задачу.

Это сообщение отредактировал(а) Дрон - 2.10.2008, 12:33

угу..   




не всегда.. или точнее, слишком много бесполезной и не нужной работы какой-то..

представь себе ситуацию.. у тебя около 300 методов в EJB и каждый их них возвращает определённый тип ( к сожалению не один и тот же )..
так вот.. заварачиваем <Warning> и <неизвесный Тип> в один объект => <неизвестный тип> постоянно разный ява объект. это значит в Wapper-e ожидаем Object.

это значит когда-то придётся делать cast на нужный на тип ява. бред полный => очень много работы какой-то бесполезной.

и ещё нужно на каждый метод писать заполнение Warning-а ( к сожалению у меня эта трабла не решается автоматом ), а потом в другом месте делать cast на объект данного типа и не забыть проверить (!), если ли там Warning   

как было бы классно в одном месте бросать warning в другом получать его и обрадатывать   

Жесть. Ты эта, заканчивай с 16-ти часовым рабочим днем. На здоровье отражается 

Тут вопрос в том, как обрабатывать подобные Warning:
Это обязательно как с Exception, или по желанию? 
Сколько этот Warning должен жить (не забываем, что это объект и под него выделена память)? Если на один уровень в верх по иерархии вызовов, то крайне неудобно. Если до бесконечности пока Warning не будет обработан, то в долгоживущих тредах (например в том же пуле), Warning будут копиться. Указать при выбрасывании Warning сколько он должен жить, тоже не получится, мы же не всегда знаем откуда и как будут идти вызовы.

На мой взгляд идея надумана - ну возвращайте не один Exception а два, три и т.д.
Или надо еще какой-то "мягкий" вариант ? Ну тогда тоже ерунда - он в данном случае ничем не отличается от обычного Exception.
Если не хочется ловить, а генерить Exception хочется - ну делайте его Runtime.

Вообщем тема какая-то странная - автор толком объяснить не может, что он хочет. И смысл тогда обсуждать ?

LSD, да я согласен, что всё это проблема. Но в то же время я не сомневаюсь, что она решима, и, будь на то необходимость, её бы встроили в язык. Пока, видимо, реальной необходимости нет.

И не сочти за наезд на Java (мой пыл как-то поостыл  ), но если что-то подобное и станут делать, то уж точно не в Java. Я не говорю, что Microsoft -- это паровоз современных языков, но в то же время Sun совсем не спешит вносить серьёзные изменения в Java, уж очень они консервативны.

речь идёт не о Exception, а о Warning.. они разные по семантике.. 




ситуация описана в пятом топике..     

Да есть такой момент. Единственное серьёзное нововведение на уровне JRE - аннотации, ну и плюс ещё парочка на уровне компилятора.

это обязательно..   

warning сразу умирает также, как и Exception находящийся в блоке catch (Exception pEx) {}