пример:



Концепция 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) {}

  

polosatij, то что вы хотите, если я правильно понимаю, вполне может быть реализовано по аналогии с ExceptionHandler'ами, о которых уже упомянул LSD.
Может выглядеть как то так:

ivg, большое спасибо тебе, что ты не поленился написать код   

однако твоё решение ничем не отличается от простой инстанции Warning, и последняя даже выходит лучше, если речь идёт о распределённых контейнерах и кластерах.. + статик сюда не катит..

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

В таком контексте на мой взгляд это совершенно не требует понятия Warning. В конце концов такие вещи решаются простым выставлением какого-либо кода, который всегда можно проверить. Излишнее усложнение и утяжеление языка не идет ему на пользу.
Если посмотреть исходники того же MFC из Visual C++ - это читать уже крайне тяжело. Код должен быть в первую очередь понятен и не перегружен излишними конструкциями. 
Иногда вижу последствия использования Generic в Java и не всегда это хорошо читаемо и понятно.

P.S. Я цикл do .. while использовал последний раз больше года назад, а то и больше.

к сожалению ты ошибаешься.. представь себе ситуацию:

server <-> логика <-> ejb <-> backing bean <-> jsf

теперь, по сути вещей, в ejb есть какая нибудь метода:

public ArrayList < FooBar > doSomething(тут 3-7 параметров) throws BarException, FooException {...}

по сути дела, ты передашь лист с FooBar в backing bean..

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

Можно просто сделать, чтобы функция ВСЕГДА кидала эксепшн, то есть, её штатным режимом было бы возвращение результата через эксепшн. Тогда можно будет возвращать разные типы в зависимости от варнинга, причём если вызывающиего модуля не интересует варнинг, он может не смотреть подтип.

Добавлено через 19 секунд
P.S. Кстати, а где есть Warning?

так нельзя сделать.. это чистое нарушение семантики..

------------

в общем, я сделал так:



Aмерику я не открыл и посему продисел 4е дня в обработке warning-ов и возвращающих типов   




не наю.. не видел.. нигде не пробегал?   

Это сообщение отредактировал(а) polosatij - 8.10.2008, 21:06

А вы не задумывались о том, что накладные расходы на Exception намного выше, чем на простой вызов метода?

Почему это? Exception -- это дополнительный канал возврата информации из метода. Разработчики языка решили разбить каналы возврата информации на две группы: основной и дополнительные. Группы всего две. 

А Вы, фактически, хотите сделать, чтобы их было три. Поскольку больше групп сделать нельзя, я и предложил устранить одну из групп, перейдя к одноранговой системе, управляемой только типами.

потому как,

1). читай выше, что сказал LSD
2). Exception - это исключение, кот. говорит, сорри, я ничего сделать на данном уровне не могу, а Warning - это вообще не исключение, оно вообще сюда никаким макаром не катит.. ты в борщ хочешь кинуть яблоки => съесть можно, но уже что-то не то..

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

автор приводил пример...



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


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

... плюс данный скорее всего крик души вылез из того что имееться огромный код... написанный волшебными людьми из страны Оз... который нужно по шурику заставить работать... но мне кажеться создатели языка не должны следовать подобным причинам что бы добавлять разные фичи в язык... тут уж скорее всего нужно больше заниматься рефакторингом и познавать его тонкости и ньюансы... 




Это сообщение отредактировал(а) sith - 13.10.2008, 17:44

Вообще-то Дрон, уже здесь уже объяснил чем это отличается от Exception.



И этот вопрос тоже уже обсуждался.


Почитай всю тему, а не только первый пост.